<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">This thread behavior over fork is the same on Mach, BTW.<div class=""><br class=""></div><div class="">Apple extended posix_spawnp to take a “Stop at first instruction” attribute, basically just running PT_TRACEME for us. That has ended up being very handy because we get all the nice cleanup behavior that pthread_spawn does, but still get the one thing the debugger needs fork for… Don’t know whether it does something useful for locks, however.</div><div class=""><br class=""></div><div class="">Jim</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 16, 2017, at 2:06 PM, Tamas Berghammer via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" class="">lldb-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On linux when you call fork the new process will only have the thread what called fork. Other threads will be ignored with leaving whatever dirty state they had left in the new process. Regarding execve it doesn't do fork so we would have to do fork & execve what have the same issue (actually we are using execve as of now but it isn't different from exec in this regard).<div class=""><br class=""></div><div class="">Tamas</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Oct 16, 2017 at 1:57 PM Zachary Turner via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" class="">lldb-commits@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath <<a href="mailto:labath@google.com" target="_blank" class="">labath@google.com</a>> wrote:<br class=""></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" class="">zturner@google.com</a>> wrote:<br class="">
> Doesn’t DisableAllLogChannels acquire a scoped lock? If so wouldn’t it just<br class="">
> release at the end of the function?<br class="">
<br class="">
<br class="">
The thing is, it is unable to acquire the lock in the first place,<br class="">
because the mutex is already "locked". So, the sequence of events is<br class="">
process 1, thread 1: acquire lock<br class="">
process 1, thread 2: fork(), process 2 is created<br class="">
process 1 thread 1: release lock<br class=""></blockquote><div class=""><br class=""></div></div></div><div dir="ltr" class=""><div class="gmail_quote"><div class="">Suppose process 1 thread 1 had been executing this code:</div><div class="">```</div><div class="">lock();</div><div class="">logSomething(); // thread 2 forks when thread 1 is here.</div><div class="">unlock();</div><div class="">```</div><div class=""><br class=""></div><div class="">Doesn't thread 2 in the child process resume running from the same point? If so, it seems that both the child and parent would both gracefully unlock the lock.</div><div class=""><br class=""></div><div class="">I'm sure I'm wrong about this, but hopefully you can clarify what I'm missing.</div><div class=""><br class=""></div><div class="">As a follow-up question, why can't we use execve instead of fork / exec?</div></div></div>
_______________________________________________<br class="">
lldb-commits mailing list<br class="">
<a href="mailto:lldb-commits@lists.llvm.org" target="_blank" class="">lldb-commits@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits</a><br class="">
</blockquote></div>
_______________________________________________<br class="">lldb-commits mailing list<br class=""><a href="mailto:lldb-commits@lists.llvm.org" class="">lldb-commits@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits<br class=""></div></blockquote></div><br class=""></div></body></html>