Off-list since this tastes like it will rapidly spin out of control.
On-list since this is relevant for others participating in the discussion
Classic scenario for threading: GUI. GUI uses my module which hasn't been carefully written to be cooperative. The entire GUI pauses while it waits for my code to do its thing. No window updates, no button pushes, no way to *cancel the operation that's taking too long*.
OK, very true, I was more thinking of something like a server that uses a thread for each connection.
Luckily I already mentioned that automatic yielding is not too hard. A timed that sets a "yield asap" flag that's tested iteration of a loop should work - maybe something with even less overhead can be cooked up.
I hope this is not a serious suggestion to implement preemptive threads using fork() and tied vars. That way ithreads lie.
Actually, ithreads are slower because they don't do copy-on-write while the OS usually does.
fork() moves the problem to the OS, where bright people have already spent a lot of time optimizing things, I hope at least ;)
I suppose how much faster it is to do things within the VM rather than using forked processes depends on how much IPC happens. In your GUI example, the answer is: very little, only status updates.
The existing system you probably mean is POE
No, I wasn't. I looked it up, it's called "forks".
Besides, it would be silly as Dan has already said Parrot will support
preemptive multitasking and that's half the hard work done. The other half is designing a good language gestalt around them.
OK, as long as it doesn't hurt performance of non-threaded apps I obviously have no problem with *supporting* preemptive threading, since they're certainly useful for some applications. But coop threads are more useful in the general case - especially since they're simpler to use thanks to the near-lack of synchronization problems. Simplicity is good, especially in a language like perl.
And I resent how you talk about non-preemptive threading as not being "real" threading.
My biases come from being a MacOS user since System 6. MultiFinder nightmares.
Valid point (I'm also a long-time MacOS user), but cooperative multitasking isn't the same as cooperative threading. We're talking about the scheduling between threads inside one process; and we can avoid the lockup problem in the VM with automatic yielding.
This makes most of the problems of cooperative threading disappear, while leaving the advantages intact.
If we want to support real-time programming in Perl
No, I was merely pointing out that it's not always a step "forward" for all applications. Some people made good use with the ability to grab all the CPU time you need on old MacOS.
None of this precludes having a cooperative threading system, but we *must* have a preemptive one.
"must" is a big word; people happily used computers a long time before any threading was used ;-)
It looks like we could use both very well though
-- Matthijs van Duin -- May the Forth be with you!
