ithreads - RE: threads change

Author

RE: threads change

Jerry D. Hedden

2006-07-14, 8:03 am

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.

> 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?

> And that the entire notion of sending signals to a thread
> is dubious and not a portable concept

In what way is it dubious? Again, it was discussed and
accepted by those weighing in. Further, it works very well,
and I have released two new modules to CPAN that utilitize
this new feature: Thread::Suspend and Thread::Cancel.

As to portability, it works under all systems tested: Win32,
Solaris, Cygwin, and more. What are your specific issues
with it?

I am sorry that you were not aware of the discussions that
were going on. Do you monitor the Perl iThreads mailing
list? I'll endeavor to include it on all further 'threads'
discussion.

Artur Bergman

2006-07-14, 7:04 pm

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

> Artur Bergman wrote:
>
> 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.

>
> 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