labath created this revision.
We had a bug where if we had forked (in the ProcessLauncherPosixFork)
while another thread was writing a log message, we would deadlock. This
happened because the fork child inherited the locked log rwmutex, which
would never get unlocked. This meant the child got stu
Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it just
release at the end of the function?
On Sun, Oct 15, 2017 at 2:42 PM Pavel Labath via Phabricator <
revi...@reviews.llvm.org> wrote:
> labath created this revision.
>
> We had a bug where if we had forked (in the ProcessLau
On 15 October 2017 at 23:04, Zachary Turner wrote:
> Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it just
> release at the end of the function?
The thing is, it is unable to acquire the lock in the first place,
because the mutex is already "locked". So, the sequence of eve
what are we using fork for, out of curiosity? It seems pretty hard to make
this work. Logging isn’t the only thing in the program that might be
holding a mutex, so it seems like this could still happen.
Seems like mixing fork and mutexes is just a fundamentally bad idea, unless
I’m missing somet
On 15 October 2017 at 23:59, Zachary Turner wrote:
> what are we using fork for, out of curiosity? It seems pretty hard to make
> this work. Logging isn’t the only thing in the program that might be
> holding a mutex, so it seems like this could still happen.
>
> Seems like mixing fork and mutex
