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
