> 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.
Uhm, are you talking perl 5 here? The event checker checks for signals, we got safe
signals now. MULTIPLICITY is just allowing multiple interpreters, ithreads is letting
them run at the same time and properly clone them. If you want to use it switch
interpreters at runtime for fake threads, patches are welcome, send it and I will
apply it.
> 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).
I am sorry to say, but perl 5 is true MT.
> 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).
>
Where did you get this breaking info? ithread works with multiple CPUs and IO blocking
is not a problem.
Arthur
