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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
