legrady at gmail.com
Sat Dec 11 16:38:41 PST 2010
There's ithreads - "interpreter threads" where each thread has a
separate interpretor and special arrangements need to be made for
shared data. This is since 5.8, not to be confused with threads.pm,
which is deprecated and not available with 5.10 and later.
The Perl Object Environment, POE, supports a server-client arrangement
... the management-labour arrangement as I like to call it
Personally, I prefer to launch independent tasks rather than have
comunicating tasks ... makes debugging easier to have self-contained
entities. But then I haven't written an OS since the UWaterloo trains
On Sat, Dec 11, 2010 at 2:29 PM, <arocker at vex.net> wrote:
> In order not to embarrass myself (or Perl) at the GTALUG meeting on
> Tuesday, I'm researching the agenda. and I need help with this item:
> * How does your language handle scalability issues?
> * Applications that require many concurrent threads of execution?
> * How does the language interact with threading?
> * Does it offer other models for managing concurrent processing?
> I've never had to deal with multiple concurrent processes, and frankly
> take a dim view of applications trying to do the OS's job for it. Has
> anybody any experience in this area that I can quote?
> toronto-pm mailing list
> toronto-pm at pm.org
More information about the toronto-pm