Re: threads change

On Jul 14, 2006, at 6:21 AM, Jerry D. Hedden wrote:

> Artur Bergman wrote:
>> - 'exit' inside a thread silently terminates thread only
>> what was the reasoning for this change?
>
> Wow.  You missed a whole lot of discussion on this and other
> changes to the 'threads' module on the Perl5 Porters and
> Perl iThreads mailing lists.  I did not make these changes
> in a vacuum, but with lots of input and recommendations from
> others.  I strongly recommend that you review the
> correspondences from June and July:
>     http://www.nntp.perl.org/group/perl.perl5.porters
>     http://www.nntp.perl.org/group/perl.ithreads
>
> As to this specific change, it was started by the
> observation that exiting from 'main' with threads running
> produced a warning while exiting from a thread did not.
> When this inconsistency was brought up and discussed, the
> consensus of those weighing in on the issue was that exiting
> a thread should exit the thread only and not the whole app,
> and further that it should not produce a warning.  Again,
> see the mailing list archive for the discussion.
>

Nevertheless I object, it was a conscious decision to have exit() not  
exit a thread but the entire app from the start, unlike psuedo  
forking which is supposed to emulate a different process, exit() is  
supposed to act on the process and not threads. 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.

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.

>> Secondly, you do realise that
>>
>>         if (thread->interp) {
>>             dTHXa(thread->interp);
>>             PL_psig_pend[signal]++;
>>             PL_sig_pending = 1;
>>         }
>>
>> is not threadsafe in anyway?
>
> 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?

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.

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.

Artur