[compiler-rt] r267864 - [tsan] Fix Darwin GCD support after separation of Processor and ThreadState

[Dmitry Vyukov via llvm-commits]

On Mon, May 2, 2016 at 1:15 PM, Kuba Brecka <jbrecka at apple.com> wrote:
>
> Any signal that arrives between cur_thread() and ProcWire will be
> delayed, right?
>
>
> I think signals are actually not disabled during early new thread state, and
> this bug was already present before this patch :(
>
>
> Signals are delayed by default
>
>
> Ah, you mean delayed by TSan, not delayed by the system.
>
> , unless we receive a synchronous signal
> or in a blocking function.
> Signal handler still needs to look at ThreadState (that's why we have
> cur_thread async-signal-safe), but it should not touch
> cur_thread->proc1.
>
>
> Yes, that sounds right.
>
> I think there is still a remaining bug on OS X, when if a signal is
> delivered very soon in a new thread, cur_thread() is not available, because
> pthread_self() doesn’t work.  That early, the %gs segment is invalid and
> reading from TSD (which is where the thread identity is stored) thus doesn’t
> work.
>
> Just wondering, is there a way to just make sure the system doesn’t deliver
> signal to that particular thread, until we enable it at a safe point?

For normal threads (created with pthread_create) a way to do this
would be to disable all signals in parent before forking, then enable
in parent right after fork. Then the child will start with signals
disabled, then we can do all initialization and enable signals in
child. I don't know how to do it for GCD threads, though.