I wish I knew why you are discussing in -internals issue on this list.
You should be specifying behaviour not how it is implemented. A mention
of implementation is reasonable but _don't_ spend too much time. If Larry
wants it. -internals will give it to him.
Anyway, please recall that because of
On Sun, 27 Aug 2000, Steven W McDougall wrote:
Based on your examples, I have to assume that you are serious about
RFC1v3 item 6:
No offense, but I wouldn't have suggested it if I weren't serious.
Misguided, perhaps. Joking, no.
This is a non-starter for me. Right now, I am working on
We could either discuss alternate approaches for RFC1, or I could
submit a new RFC for a thread architecture that gives me the
performance I want.
Both are more than welcome. (If you want alternate approaches or
counter-arguments to be fully documented, then doing both in an RFC
would
as in the non-threaded case, or do we get
$global::{foo} - *global::foo - global::foo - { print 1 }
$thread::{foo} - *thread::foo - thread::foo - { print 2 }
Okay, I understand. Here's how I perceive it
There is no global::foo, just two thread-specific foos. In which
On Sat, 26 Aug 2000, Steven W McDougall wrote:
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
No? I'll admit that it may run through the compile and run modes
multiple times, but
Users can (and do) write open code in modules.
I don't understand. Do you think that needs to be prevented?
No, I just want to know what happens when they do it.
Let's look at an example.
1. Non-threaded
#!/usr/local/bin/perl
sub foo { print 1 }
foo();
eval 'sub foo {
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
