[Lldb-commits] [PATCH] D38938: Logging: provide a way to safely disable logging in a forked process

[Jim Ingham via lldb-commits]

See my other message.  In a ptrace based system the inferior has to call  PT_TRACEME to signal it should be stopped at the first instruction.  So you do need to run that code.  As I said, Apple added an extension to posix_spawnp to do this for us.

Jim


> On Oct 16, 2017, at 2:17 PM, Zachary Turner via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> Ahh wait, sorry.  I meant posix_spawn, not execve
> 
> On Mon, Oct 16, 2017 at 2:16 PM Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote:
> I guess what I mean is, my understanding is that the only "advantage" (if you can even call it that) of using fork + exec over execve is that fork + exec allows you to run additional code between the fork and the exec.
> 
> Do we actually rely on that?  Why do we need it to do fork at all?  Why can't we just execve from the parent process without doing a fork at all?
> 
> On Mon, Oct 16, 2017 at 2:06 PM Tamas Berghammer <tberghammer at google.com <mailto:tberghammer at google.com>> wrote:
> 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).
> 
> Tamas
> 
> On Mon, Oct 16, 2017 at 1:57 PM Zachary Turner via lldb-commits <lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>> wrote:
> On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote:
> On 15 October 2017 at 23:04, Zachary Turner <zturner at google.com <mailto:zturner at google.com>> 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 events is
> process 1, thread 1: acquire lock
> process 1, thread 2: fork(), process 2 is created
> process 1 thread 1: release lock
> 
> Suppose process 1 thread 1 had been executing this code:
> ```
> lock();
> logSomething();  // thread 2 forks when thread 1 is here.
> unlock();
> ```
> 
> 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.
> 
> I'm sure I'm wrong about this, but hopefully you can clarify what I'm missing.
> 
> As a follow-up question, why can't we use execve instead of fork / exec?
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171016/24ee4a0f/attachment.html>