Home > Archive > ithreads > June 2007 > Thread Exit [was RE: threads change]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Thread Exit [was RE: threads change]
|
|
| Jerry D. Hedden 2006-07-18, 8:04 am |
| > At 2:29 AM -0700 7/18/06, Artur Bergman wrote:
>
> Well, that's what the "threads" module should do then.
Let's get the requirements down before we worry about implementation,
shall we, folks. (From what I envision, there will be no need to mess
with CORE::exit for these changes - it can all be done in threads.xs.)
First of all, do we have a consensus on changing anything? I think so:
Rafeal, Artur, Liz and Jan are in favor of the general concept of exit()
terminating the app, and threads->exit() terminating the thread. Any
dissensions?
Next is the question of this being overridable such that exit() can be
made to just terminate just the thread. Liz and Artur are in on this.
Others?
Assuming overriding is allowed, my suggestion for design would be to
have both of the following:
1. Global basis:
use threads 'exit' => 'threads_only';
# or just
use threads 'exit' => 'threads';
2. Per thread basis:
my $thr = threads->create({'exit' => 'thread_only'}, 'thr_func',
....);
# or just
my $thr = threads->create({'exit' => 'thread'}, 'thr_func', ...);
(Implementation can most easily be handled by adding a flag to the
threads structure in threads.xs, and action would taken accordingly
after trapping an 'exitting' thread.)
| |
| Elizabeth Mattijsen 2006-07-18, 7:08 pm |
| At 2:44 PM +0100 7/18/06, Dave Mitchell wrote:
>On Tue, Jul 18, 2006 at 05:46:09AM -0700, Jerry D. Hedden wrote:
>
>No, I agree (it was originally my suggestion).
>
>
>I'm not convinced of the need. Why can't the user just do
>
> BEGIN {
> package CORE::GLOBAL;
> sub exit { thread->exit }
> }
>
>if they really wish to override the module author's wishes?
Because that would apply to all threads then, including the main
thread? Which may not be what you want?
Liz
| |
| Dave Mitchell 2006-07-18, 7:08 pm |
| On Tue, Jul 18, 2006 at 05:46:09AM -0700, Jerry D. Hedden wrote:
> First of all, do we have a consensus on changing anything? I think so:
> Rafeal, Artur, Liz and Jan are in favor of the general concept of exit()
> terminating the app, and threads->exit() terminating the thread. Any
> dissensions?
No, I agree (it was originally my suggestion).
> Next is the question of this being overridable such that exit() can be
> made to just terminate just the thread. Liz and Artur are in on this.
> Others?
I'm not convinced of the need. Why can't the user just do
BEGIN {
package CORE::GLOBAL;
sub exit { thread->exit }
}
if they really wish to override the module author's wishes?
--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
-- Bill Royston
| |
| Jerry D. Hedden 2006-07-18, 7:08 pm |
| Jerry D. Hedden wrote:
> First of all, do we have a consensus on changing anything?
> I think so: Rafeal, Artur, Liz and Jan are in favor of the
> general concept of exit() terminating the app, and
> threads->exit() terminating the thread. Any dissensions?
Dave Mitchell replied:
> No, I agree (it was originally my suggestion).
I'm with Dave, BTW. I think 'exit()' in a thread should just
terminate the thread.
I know that Artur's mantra is 'threads are threads and
processes are processes', but I don't view it that way for
Perl iThreads. For me, thread 0, the 'main' thread, isn't
really a thread; it's the main controller for the process,
and all 'created' threads are subordinate to it. I feel
that the 'main' thread should be in control, and not be
subjugated to the whims (or poor programming) in a thread.
Jerry D. Hedden wrote:
> Next is the question of this being overridable such that
> exit() can be made to just terminate just the thread.
> Liz and Artur are in on this. Others?
Dave Mitchell replied:
> I'm not convinced of the need. Why can't the user just do
> BEGIN {
> package CORE::GLOBAL;
> sub exit { thread->exit }
> }
> if they really wish to override the module author's wishes?
If we do change the current thread exit functionality, I
would prefer that overriding the default behavior should be
supported explicitly by the module as per my original
suggestions (i.e., use threads 'exit' => 'threads_only';, and
$thr->create({'exit' => 'thread'}, ...); ).
| |
| Eric Rybski 2006-07-18, 7:08 pm |
| --- "Jerry D. Hedden" <jdhedden@cpan.org> wrote:
> Jerry D. Hedden wrote:
>
> Dave Mitchell replied:
>
> I'm with Dave, BTW. I think 'exit()' in a thread should just
> terminate the thread.
>
> I know that Artur's mantra is 'threads are threads and
> processes are processes', but I don't view it that way for
> Perl iThreads. For me, thread 0, the 'main' thread, isn't
> really a thread; it's the main controller for the process,
> and all 'created' threads are subordinate to it. I feel
> that the 'main' thread should be in control, and not be
> subjugated to the whims (or poor programming) in a thread.
>
After reading through the entire thread on this topic, two concerns have been
growing in my mind:
1. What is the desired intent of ithreads, from a flow-structure perspective?
Is one of the intents of ithreads to deprecate the fork system call or happily
co-exist with it?
It seems that part of the disagreement about exit() in general is due to
different perceptions of what a perl "thread" should be. A classic example of
this is the discussion of whether or not the main thread should be allowed to
exit with child threads still allowed to continue running or not.
Over the last two years of professional application ithread-interface
programming, I personally have grown to perceive it as a functional abstraction
of fork(), with semantics for interprocess communication (shared vars) and flow
control (semaphores & signals). Unless I'm mistaken, one of the core intents
the current heavy-weight thread model of ithreads was to model this exact
behavior (likely for file/package variable scope and import compatibility with
existing modules).
However, using ithreads does _not_ prevent one from still using the fork()
function call (however convoluted the result may be). This means one could
have separate processes running separate instances of identical copies of
already running threads! In such a case, it is critical to retain a clear
distinction between functions that operate on a process and those that operate
on the current thread.
2. If functionality is provided by ithreads to easily override the global
exit() function, what are the implications for existing modules that are
concerned with process-level control (e.g. they expect that exit will stop the
current process and return the exit state to the kernel)?
It seems like adding an easily overridden CORE::exit() could do more harm than
benefit: it would add potential incompatibility with existing modules without
warning of which modules could or would be affected.
If an end application implementer wishes to override the exit() function to
exit a thread not the entire process, they can always keep those changes
restricted to their own namespace (made simpler, perhaps, with a import()
parameter); however, if they wish to affect all namespaces by overriding
CORE::exit(), they honestly should do it only at their own risk (knowing that
the CPAN modules they are using may or may not break as a result).
My worry is that if the threads module provides any module author an easy
import interface to do the latter, then it almost implicitly suggests that
action is safe and reliable to use in general. I would personally feel much
more comfortable to including:
BEGIN {
package CORE::GLOBAL;
sub exit { thread->exit }
}
as a suggestion in the POD notes section for application developers--and
strongly recommended _against_ using for re-usable or published modules--with
AT YOUR OWN RISK noted everywhere.
Ironically, Threads::Exit already provides an interface to override CORE::exit
anyway! Are we attempting to re-invent the wheel...?
> Jerry D. Hedden wrote:
>
> Dave Mitchell replied:
>
> If we do change the current thread exit functionality, I
> would prefer that overriding the default behavior should be
> supported explicitly by the module as per my original
> suggestions (i.e., use threads 'exit' => 'threads_only';, and
> $thr->create({'exit' => 'thread'}, ...); ).
>
>
At this point, the ithreads interface seems fairly complete, robust, and
generally lightweight. Although I consider most of the recent method
additions practical (such as those that deprecate the needs for some existing
Thread::* perl modules) and appropriate to include in the threads.pm, it is a
generally good idea to try not to pollute it with globally-affecting
semantics--especially considering it the module is distributed with core perl).
Regards,
Eric Rybski
| |
| Dave Mitchell 2006-07-19, 4:11 am |
| On Tue, Jul 18, 2006 at 08:22:11AM -0700, Jerry D. Hedden wrote:
> Jerry D. Hedden wrote:
>
> Dave Mitchell replied:
>
> I'm with Dave, BTW. I think 'exit()' in a thread should just
> terminate the thread.
Er, no; I meant exit should terminate the whole process, not just the thread.
--
There's a traditional definition of a shyster: a lawyer who, when the law
is against him, pounds on the facts; when the facts are against him,
pounds on the law; and when both the facts and the law are against him,
pounds on the table.
-- Eben Moglen referring to SCO
| |
|
|
|
|
|
|
|
|
|
|
|
|
|