On Mon, Mar 31, 2003 at 10:50:59AM -0800, Michael G Schwern wrote: > On Mon, Mar 31, 2003 at 08:13:09PM +0200, Matthijs van Duin wrote: > > I think we should consider cooperative threading, implemented using > > continuations. Yielding to another thread would automatically happen when > > a thread blocks, or upon explicit request by the programmer. > > > > It has many advantages: > > It has major disadvantages: > > I must write my code so each operation only takes a small fraction of time > or I must try to predict when an operation will take a long time and yield > periodicly. > > Worse, I must trust that everyone else has written their code to the above > spec and has accurately predicted when their code will take a long time.
It's very easy to automatically translate threads at the language level into cooperative instructions at the VM level. I proposed it to perl5-porters in February 1997, and I proposed it to perl6-language in January 2001. At the language level, cooperative multitasking would look and feel like plain threads. I think this would allow the language to reconcile threading and callback-based I/O, but I agree it would add weight to the VM that most people don't want. > The simple reason is that with preemptive threads I don't have to worry > about how long an operation is going to take and tailor my code to it, > the interpreter will take care of it for me. All the other problems with > preemptive threads aside, that's the killer app. Cooperative threads at the VM level don't preclude support for true threads. For example, it should be possible create a fixed number of threads that act as execution pipelines for a cooperative VM. Divorcing the system threads from the language threads gives you a couple interesting possibilities. It's possible to tune the number of system threads Perl uses. Threads tend to scale poorly after they run out of CPUs. Developers can take this into consideration and limit the number of threads a program uses. Programs are still free to spawn as many "threads" as they want, even if they request more threads than the operating system can provide. > We need preemptive threads. We need good support at the very core of the > langauge for preemptive threads. perl5 has shown what happens when you > bolt them on both internally and externally. It is not something we can > leave for later. Agreed. > Cooperative multitasking, if you really want it, can be bolted on later or > provided as an alternative backend to a real threading system. Disagreement, but I've grown accustomed to it. Carry on. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
