[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181102153352.GH5150@brightrain.aerifal.cx>
Date: Fri, 2 Nov 2018 11:33:52 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Deadlock when calling fflush/fclose in multiple threads
On Fri, Nov 02, 2018 at 03:15:51PM +0000, John Starks wrote:
> >
> > I think we just have to move the __ofl_lock to the top of the
> > function, before FLOCK, and the __ofl_unlock to after the
> > fflush/close. Unfortunately this makes fclose much more serializing
> > than it was before, but I don't see any way to avoid it.
> >
>
> Perhaps you could keep a global count of FILEs that are still being
> flushed after having been removed from the list. fflush could
> perform a futex wait on this becoming 0.
I think such an approach is plausible, but involves the kind of
complex and error-prone direct use of atomics I'm actively trying to
eliminate. The same could be done without low level hacks via clever
use of rwlocks or a mutex+condvar pair, but all of these involve
namespace-safety issues and a lot more code than should be introduced
into minimal static programs using stdio.
For what it's worth, the only consumers of the open file list that can
be executed more than once are fflush(NULL), fclose, and __ofl_add
(used by fopen, etc.).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
