RFC1v3 says
5. Threads are a runtime construct only. Lexical scoping and
compile issues are independent of any thread boundaries. The
initial interpretation is done by a single thread. use Threads may
set up the thread constructs, but threads will not be spawned
until runtime.
However, the distinction between compile time and run time that it
relies on doesn't exist in Perl. For example, if we chase through
perlfunc.pod a bit, we find
use Module;
is exactly equivalent to
BEGIN { require Module; import Module; }
and
require Module;
locates Module.pm and does a
do Module.pm
which is equivalent to
scalar eval `cat Module.pm`;
and eval is documented as
eval EXPR
the return value of EXPR is parsed and
executed as if it were a little Perl program.
Users can (and do) write open code in modules.
There is nothing to prevent users from writing modules like
# Module.pm
use Threads;
Thread->new(\&foo);
sub foo { ... }
Users can also write their own BEGIN blocks to start threads before
the rest of the program has been compiled
sub foo { ... }
BEGIN { Thread->new(\&foo) }
Going in the other direction, users can write
require Foo.pm
or even
eval "sub foo { ... }";
to compile code after the program (and other threads) have begun execution.
Given all this, I don't think we can sequester thread creation into
"run time". We need a model that works uniformly, no matter when
threads are created and run.
- SWM
