Earlier, Leon Timmermans wrote:
: * Code sharing is actually quite nice. Loading Moose separately in a          
                                                                      
: hundred threads is not. This is not trivial though, Perl being so             
                                                                      
: dynamic. I suspect this is not possible without running into the same         
                                                                      
: issues as ithreads does.                                                      
                                                                      

On Fri, Oct 15, 2010 at 01:22:10PM +0200, Leon Timmermans wrote:
> On Wed, Oct 13, 2010 at 1:13 PM, Tim Bunce <tim.bu...@pobox.com> wrote:
> > If you wanted to start a hundred threads in a language that has good
> > support for async constructs you're almost certainly using the wrong
> > approach. In the world of perl6 I expect threads to be used rarely and
> > for specific unavoidably-bocking tasks, like db access, and where true
> > concurrency is needed.
> 
> I agree starting a large number of threads is usually the wrong
> approach, but at the same time I see more reasons to use threads than
> just avoiding blocking. We live in a multicore world, and it would be
> nice if it was easy to actually use those cores. I know people who are
> deploying to 24 core systems now, and that number will only grow.
> Processes shouldn't be the only way to utilize that.

We certainly need to be able to make good use of multiple cores.

As I mentioned earlier, we should aim to be able to reuse shared pages
of readonly bytecode and jit-compiled subs. So after a module is loaded
into one interpreter it should be much cheaper to load it into others.
That's likely to be a much simpler/safer approach than trying to clone
interpreters.

Another important issue here is portability of concepts across
implementations of perl6. I'd guess that starting a thread with a fresh
interpreter is likely to be supportable across more implementations than
starting a thread with cloned interpreter.

Also, if we do it right, it shouldn't make much difference if the new
interpreter is just a new thread or also a new process (perhaps even on
a different machine). The IPC should be sufficiently abstracted to just work.

> > (Adding thread/multiplicity support to NYTProf shouldn't be too hard.
> > I don't have the time/inclination to do it at the moment, but I'll fully
> > support anyone who has.)
> 
> I hate how you once again make my todo list grow :-p

"Well volunteered!"  ;)

Tim.

Reply via email to