Re: Threads signalling issue [was RE: threads change]

On Jul 14, 2006, at 10:58 AM, Jan Dubois wrote:

> On Fri, 14 Jul 2006, Jerry D. Hedden wrote:
>> If you mean that PL_psig_pend[signal], etc. should be
>> locked:
>>
>>          /* Set the signal for the thread */
>>          thread = SV_to_ithread(aTHX_ ST(0));
>>          MUTEX_LOCK(&thread->mutex);
>>          if (thread->interp) {
>>              dTHXa(thread->interp);
>>
>>              /*** SET A "SIGNAL" LOCK HERE ***/
>>              PL_psig_pend[signal]++;
>>              PL_sig_pending = 1;
>>              /*** UNLOCK HERE ***/
>>
>>          }
>>          MUTEX_UNLOCK(&thread->mutex);
>>
>> then what should the fix be?  Anyone?
>
> I explained before that this code is threadsafe because the actual  
> value
> of PL_psig_pend[signal] is irrelevant as long as it is set to a non- 
> zero
> value, which is what you'll do even if the increment is non-atomic.
>
> There is also no problem if the receiving thread processes the signal
> before PL_sig_pending has been set. All that is going to happen  
> that it
> will waste a few cycle checking for pending signals again and not
> finding any.
>
> There is no need to add any locking to the code above as long as Perl
> isn't implementing "queued" signals.
>
> Cheers,
> -Jan
>
> PS: I'm not seeing any of Artur's messages; aren't they being  
> copied to
> p5p?
>
>

It is threadsafe in the sense you won't crash, but PL_sig_pending  
might be set to 0 by the running thread and thus not cause the signal  
to be delivered until another signal is raised.

I don't think the fix is to add locking into the dispatcher :D

I guess a moderator needs to add me.

Artur