<div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Seems like mixing fork and mutexes is just a fundamentally bad idea, unless I’m missing something (which i very well could be)</div><br></div><div><div class="gmail_quote"><div>On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 October 2017 at 23:04, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it just<br>
> release at the end of the function?<br>
<br>
<br>
The thing is, it is unable to acquire the lock in the first place,<br>
because the mutex is already "locked". So, the sequence of events is<br>
process 1, thread 1: acquire lock<br>
process 1, thread 2: fork(), process 2 is created<br>
process 1 thread 1: release lock<br>
everything goes well from now on in process 1...<br>
process 2, thread one (and only). acquire lock:<br>
BANG.<br>
Process 2 is deadlocked because there is noone to release the lock there.<br>
</blockquote></div></div>