Artur Bergman wrote: > - 'exit' inside a thread silently terminates thread only > what was the reasoning for this change?
Jerry D. Hedden replied: > 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. Artur Bergman responded: > 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. It's a shame this wasn't documented in the POD in the first place. > 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. > 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? 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. > 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?
