> > 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 case,
> the eval'd foo would create (or replace) that thread's previous foo.
[examples snipped]
Based on your examples, I have to assume that you are serious about
RFC1v3 item 6:
6. Modules should be loaded into the thread-global space when used
[...]
Subsequent threads should then reslurp these modules back in on
their start up.
[...]
each thread needs to reuse the original modules upon creation.
[...]
This, of course, could lead to massive program bloat
This is a non-starter for me. Right now, I am working on apps that may
create 10 threads per *second*. I cannot possibly get the performance
I need if every thread has to recompile all its own modules.
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.
- SWM
