Re: threads change

On Jul 14, 2006, at 9:22 AM, Jerry D. Hedden wrote:

>
> It's a shame this wasn't documented in the POD in the first
> place.
>

I am pretty sure that Sarathys and mine original intent is documented  
on the mailing list.

>
>> If code is running in  a thread or no doesn't mean it
>> should have to act differently.
>>
>> I also think exiting from a thread is something that the
>> developer  should be aware of is happening, and that is
>> why it is giving the  warning.
>
> That is what started off the whole discussion:  Exiting from
> a thread was NOT issuing a warning.

Then that should have been the fix.

>
>> I read parts of the message and I still disagree, and I
>> did voice  this privately to Nicholas, which in retrospect
>> was the wrong thing  to do.
>
> If you consciously decided not to participate in the open
> discussion on the matter while it was in progress, then why
> are you objecting now after a consensus was reached and
> subsequently implemented?
>

Because I didn't think it would actually happen, it breaks the  
threads are threads, process are process semantics.

If a module author uses exit(), they stated a wish that the  
application should exit, not that the thread was to exit. If they  
wanted it to be catchable they would have used die;

>
> If you can sway the consensus the other way, I'd be glad to
> patch 'threads' to modify the behavior accordingly.  If
> anyone else agrees that the exiting behavior of threads
> should be changed, please speak up.
>
>
> Artur Bergman wrote:
>> Secondly, you do realise that
>>
>>         if (thread->interp) {
>>             dTHXa(thread->interp);
>>             PL_psig_pend[signal]++;
>>             PL_sig_pending = 1;
>>         }
>>
>> is not threadsafe in anyway?
>
> Jerry D. Hedden replied:
>> In what way is it not thread safe?  Do you have a fix for
>> whatever bug you think exists?  Have you looked at the test
>> suite?  How is it deficient?
>
> Artur Bergman responded:
>> You are using another interpreter, that is possibly currently
>> running, and then acting on it with non locking semantics. At best
>> your ++ will be lost.
>
> You code snippet is incomplete.  There are locks:
>
>         /* Set the signal for the thread */
>         thread = SV_to_ithread(aTHX_ ST(0));
>         MUTEX_LOCK(&thread->mutex);
>         if (thread->interp) {
>             dTHXa(thread->interp);
>             PL_psig_pend[signal]++;
>             PL_sig_pending = 1;
>         }
>         MUTEX_UNLOCK(&thread->mutex);
>
> If this is not implemented correctly, then please submit a
> patch.
>

Please humour me and explain to me how that lock is going to protect  
thread->interp? thread->interp is currently running.

>
>> While I guess it is fine to use the signal system to pass
>> information, I would define a new signal type and just use
>> that to  awake the other thread and get it from the
>> threads.xs module.  You are  again mixing the notion of a
>> process and a thread, and code that is  supposed to work
>> on inter process signals will get confused.
>
> I fail to see this.  Can you provide an example where such
> confusion might occur?

Apart from the above race, I am withdrawing this, I think it is  
confusing that signals within the process and from outside the  
process get different semantics.

Artur