Threads. Design. Go for it
Dan Sugalski
Religion. It's also very obvious that there is more than one One True
Thread Religion. And it's *definitely* obvious that I'm getting
cranky.
So.
This is everyone's chance. You have what you think is the Right Way
to do it? Fine. Time for design details.
Your constraints:
1) A POSIX-style "everything is shared implicitly" mode must be
available. It may be slow.
2) A perl 5 iThreads "it's not a thread, it's a fork. Well, sorta..."
mode must be available
3) You must give details of the proposed changes/additions to the
design of the engine and underlying code.
4) Keep in mind that the engine has events and asynchronous I/O
floating around. These are a given.
5) Be very aware of the existence of SMP machines, and the potential
fun that can ensue with a combination of SMP, DOD, and GC. (You may
assume that the current copying GC can be replaced with a non-copying
version when running with threads)
6) Bytecode can't, under any circumstances, crash the interpreter
because of thread programming errors. (Barring implementation
problems)
I make no promises that a proposal will get anything other than
ignored. The more of the current core design a proposal thinks should
be replaced, the less likely it is to go anywhere. Handwave on
details at your peril. No warrantee is expressed or implied. Slippery
when wet. Your mother says you never write, and you should wear a
sweater.
I may or may not ask questions, make pointed comments and/or
observations, or say anything about any proposal. It's possible, and
likely, that there are elements of parrot's design that I've
insufficiently expressed which may torpedo a proposal, though I'll
try to detail those when they come up.
This, as they say, is your one and only chance. Go for it, and good
luck. Please start a *new* thread, with a uniquely identifying
subject line (a proposal name or your name in it is good) so I have
at least some hope of keeping it all straight.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Josh Wilmes
> Your constraints:
>
> 2) A perl 5 iThreads "it's not a thread, it's a fork. Well, sorta..."
> mode must be available
For those of us who aren't particularly familiar with ithreads, what does
this imply? What's different, and why must it be done at the level of
parrot, not perl?
--Josh
Jeff Clites
The unique feature of ithreads is that data is not shared between
threads by default, but rather has to be marked as shared to be visible
from multiple threads. (If you have Perl 5.8, you can read more about
this in the perlthrtut man page; in particular, the section "Threads
And Data".)
As far as what level needs to implement them, I'd say that parrot has
to do enough to make it possible for an HLL to expose ithreads-style
threading. Due to the cross-language nature of parrot, practically
speaking this probably means that the semantic needs to exist at the
parrot level. (For instance, an ithread created in Perl code could load
a parrot bytecode library implemented in Python; calling into code
inside this library shouldn't allow access to "unshared" data from
other ithreads.)
JEff
Josh Wilmes
> As far as what level needs to implement them, I'd say that parrot has
> to do enough to make it possible for an HLL to expose ithreads-style
> threading. Due to the cross-language nature of parrot, practically
> speaking this probably means that the semantic needs to exist at the
> parrot level. (For instance, an ithread created in Perl code could load
> a parrot bytecode library implemented in Python; calling into code
> inside this library shouldn't allow access to "unshared" data from
> other ithreads.)
OK, thank you, that (the cross-language issue) is what I was looking for.
--Josh
Dave Mitchell
> As far as what level needs to implement them, I'd say that parrot has
> to do enough to make it possible for an HLL to expose ithreads-style
> threading. Due to the cross-language nature of parrot, practically
> speaking this probably means that the semantic needs to exist at the
> parrot level. (For instance, an ithread created in Perl code could load
> a parrot bytecode library implemented in Python; calling into code
> inside this library shouldn't allow access to "unshared" data from
> other ithreads.)
The other big thing about ithreads is that the 'not shared by default'
model implies that each time a new thread is created by a request from the
HLL, the whole current interpreter state must be copied (or some COW
scheme interposed0) so that when the new thread makes changes to a
pre-existing variable, that change isn't seen by any of the ancestor
threads. That implies some support from parrot.
--
O Unicef Clearasil!
Gibberish and Drivel!
- "Bored of the Rings"