"Graciliano M . P ." wrote:
>
> # New Ticket Created by Graciliano M. P.
> # Please include the string: [perl #22922]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22922 >
>
> There is some plan of how threading will work on Parrot?
Each thread will have it's own parrot interpreter.
> Since Parrot use registers, like an CPU, how will work the register
> between the different threads?
Each set of registers belongs to a specific interpreter. Thus, each
thread will have it's own set of registers.
> Will be a real threading sytem, made by the OS? Or an threading system
> inside the VM?
Yes, it will be either an OS threading system or a user space threading
system. There's no reason why it shouldn't work equally well with
pthreads or pth, or any other threading system which provides sufficient
functionality.
Hmm... unless you're thinking of something like Java's green_threads?
Yes, something like that *could* be done... I wouldn't want to be the
one to implement it, though :)
Hmm... once we have event handling done and can create timer events (for
context switches), one could probably build a threading system *on top*
of parrot, without needing to have parrot directly support it.
Hmm... threading implemented by timer/context-switch events might be
quite useful for when we want to run Java on Parrot, since it's all done
with a single interpreter... which is what we need there, since
everything shared across all threads by default.
> How to share data, and objetcs?
<WAG>Probably through a type special "shared" PMC, which contains in
it's data segment a mutex and a pointer to the actual PMC; doing an
operation on this container would lock the mutex, then do the op on the
actual PMC, then unlock the mutex. The containing PMC header would
belong to the interpreter it resides in, the mutex and the contained PMC
would be shared.</WAG>
This is how we'd do it with normal threading (OS supported, or through a
user-level threading library (but still at the C level))... obviously,
if we do something like java's green_threads, then we don't have to do
anything at all to make something shared.
> And how about objets linkeds with native objetcs (C++), can we share?
Similarly to how other data is shared -- a normal PMC header, with
shared stuff in it's data segment.
> How about share a class, and have only the main program with
> differences?
?
> Beatiful things can be done, specially a fast threading system.
>
> I think that a good way is to make an internal threading system inside
> the VM, like an OS make in our machines, and we can be able to share
> native functions/objetcs with that. And also implement threadin in OS
> that doesn't have this, or where is hard to implement. The biggest
> problem is with instructions, specially externals, that take some time
> to process, since this make the other thread wait to go.
This is the same problem that Java's green_threads has. AFAIK, while
one can avoid *some* blockages, there will be times when it's
unavoidable.
E.g., if we perform a blocking read, the VM threading system can detect
what we're trying, and use select() to see if the fd is readable, and if
not, switch to another thread instead of blocking. But if we call some
other native C/C++ function, one which the VM doesn't know how to
schedule around, then the whole VM will block.
> But some interruption system can be used, to can play the second
> thread, and go back to the first just after the instruction backs.
Best yet -- have an OS timer fire off every so often; this enqueues a
timer event. Our normal event handling deques that event, and in the
handler, we would choose to interpret it as a context-switch event --
this saves the continuation which we would "normally" return using,
fetches the continuation of the next thread to wake up, and then
invokcc's that fetched continuation.
We already have plans for supporting each of these things seperately;
turning them into a VM-level threading system might not really be that
hard.
> Or maybe have the 2 styles, one in the OS and one in the VM, and will
> be possible to work with native threading too (in external libraries).
Indeed; further, we can even have multiple OS-threads, and in each of
them, have one or more VM-threads.
> I think that put threading in the TODO list from the beggining is
> important, since this is one of the last things to do, but need a lot
> of changes in the structure and a good work. Plan how to do this from
> the beggining and make the structure to receive that in the end is
> important, and Parrot has everything to have a good threading system,
> since we already saw the different styles in Perl, Java, etc... and
> know what is good or not.
What I want to know, is what happens if we try and pass a continuation
(or a subroutine, for that matter) from one thread to another, and then
invoke it in the wrong thread? :)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
