--- "Jerry D. Hedden" <[EMAIL PROTECTED]> wrote:
> 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.
>
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:
> > 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'}, ...); ).
>
>
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
