Arthur Bergman wrote:
> In an effort to rest my braine from a coredumping perl5 I started to think a bit on
>threading under parrot?
>
> While it has been decided that perl should be using ithread like threading, I guess
>that is irelevant at the parrot level. Are you
> going to have one "virtual cpu" per thread with it's own set of registers or are you
>going to context switch the virtual cpu?
>
> If it was one virtual cpu per thread then one would just create a new virtual cpu
>and feed it the bytecode stream?
>
> Is there anything I could help with regarding this?
>
> Arthur
The context is almost identical to that of Perl5's MULTIPLICITY which passes the
perl-interpreter to each op-code. Thus there is
inherent support for multiple ithread-streams. In the main-loop (between each invoked
op-code) there is an event-checker (or was in
older versions at any rate). It doesn't do anything yet, but it would make sence to
assume that this is where "context-switches"
would occur, which would simply involve swapping out the current pointer to the
perl-context; A trivial matter.
The easiest threading model I can think of would be to have a global var called
"next_interpreter" which is always loaded in the
do-loop. An asynchronous timer (or event) could cause the value of "next_interpreter"
to be swapped. This way no "schedule"
function need be checked on each operation. The cost is that of an extra indirection
once per op-code.
True MT code simply has each thread use it's own local interpreter instance. MT-code
is problematic with non MT-safe extensions
(since you can't enforce that).
In iThread, you don't have a problem with atomic operations, but you can't take
advantage of multiple CPUs nor can you garuntee
prevention of IO-blocking (though you can get sneaky with UNIX-select).
-Michael
