>
>
> 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.
There are bound to be semi-portable methods of non-blocking IO. UNIX-select
has to have an equiv on NT. Granted it's a lot more complicated. Basically
you could have IO ops trigger an event-based iThread swap, which causes select
to be invoked. I've always thought this was the most efficient model for
single-CPU machines. The biggest problem was always segmenting one's code
into call-backs. Well, with op-codes, we have a natural division. We have a
tight inner loop that occasionally hits a dispatcher on a complexity level
similar to a GUI. You're much better prone to handle event-based operations
(which means higher level languages can be built atop such a parrot-design).
Food for thought.
-Michael
