On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
> >
> > What we're going to do is fire up a new interpreter for each thread. (We
> > may have a pool of prebuilt interpreters hanging around for this
> > eventuality) Threading *is* essential at the parrot level, and there are
> > even a few (as yet undocumented) opcodes to deal with them, and some stuff
> > that's an integral part of the variable vtable code to deal with it.
> > Whether it's considered ithread-like or not's up in the air--it'll probably
> > look a lot like a mix.
> >
> > I'm also seriously considering throwing *all* PerlIO code into separate
> > threads (one per file) as an aid to asynchrony.
>
> Just remember the cost in context-switching, plus the lack of scalability as
> the number of file-handles increases. Linux thread-context-switches are
> relatively brutal compared to say Solaris. Additionally you're consuming a
> new stack area for each file-handle. That's lots of overhead.
One idea I haven't seen mentioned is have a fixed number of system
threads to service a potentially larger pool of parrot interpreters.
Essentially, physical threads become execution pipelines for the
virtual machine. The limit on system threads can be tuned to
optimally spread execution across available CPUs. It could be as
small as 1 on single-processor systems that don't switch thread
contexts well.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
