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

[Zachary Turner via lldb-commits]

Ahh wait, sorry.  I meant posix_spawn, not execve

On Mon, Oct 16, 2017 at 2:16 PM Zachary Turner <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>
> 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> wrote:
>>
>>> On Sun, Oct 15, 2017 at 3:15 PM Pavel Labath <labath at google.com> wrote:
>>>
>>>> On 15 October 2017 at 23:04, Zachary Turner <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
>>> 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/5db15d0b/attachment-0001.html>