other than the fork issue on win32, it can be done with events."RA" == Rod Adams <[EMAIL PROTECTED]> writes:Except then the client wanted it to work under Win32, where I've never trusted any of the pseudo-forks that perl did (esp with Network I/O going on). So I rewrote the whole thing in a language that supported threads.
Therein lies the rub. There's a lot of win32 out there, and it needs to be supported. Will parrot have a pseudo fork system (that actually works) for platforms with no native fork?
IMO, parrot should be able to support both models strongly, and not overly promote one over the other.
if that that balance happens, i will be very happy. but more people are going to come in with thread desires (as most other langs push threads and not event loops). dan and i have talked extensively on this subject and i can work with his design which will support both in a reasonable fashion. parrot must have a core event loop which can be used by any gui or other event package. it will have parrot level threads as well. how efficient those threads are vs. a single thread in parrot is one of the issues on the table.
Okay, this plus what Dan said of:
Which is why you use async I/O and events with proper callbacks. :) Using async I/O and events properly will get you better throughput than a threaded solution most of the time. It is, granted, somewhat more brain-twisting if you're not used to it.
got me thinking. (this is mostly thinking out loud, so bear with).
- Most treaded code can be converted to an event loop (+async I/O) without issue. Esp if we have co-routines.
- For the other stuff, we'd still have Type 2 threads, which gets the job done.
So, since very little will be written for parrot directly, but rather in higher level languages, could we have a mechanism which takes IMC (or higher) that _looks_ like it's doing Type 3 threads, but automagically converts them to an event loop if possible, or a Type 2 for the cases it can't?
I'm thinking this would likely have to be done at a level higher than IMC, since the higher language would have a better idea of what's going on. But I'm not sure.
By the same token, Type 3 can be faked with Type 2, and a suitable number of messages updating values.
I'm starting to think I could be happy w/ a well tuned event loop and type 2 threads. Stuff that need heavy data interaction can use an event loop. Stuff that needs easier blocking (and untimely death) protection can go go Type 2.
-- Rod
