At 04:36 PM 9/20/2001 -0400, Rocco Caputo wrote:
>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.
That adds a level of complexity to things that I'd as soon avoid. On the
other hand there's no reason we can't add it in later.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
