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
