"RA" == Rod Adams <[EMAIL PROTECTED]> writes:that is not the only way as i have pointed out. it is just a way that is promoted heavily (like java). events if done correctly are generaly faster than threads and use much less ram (no stack context created for each thread). and blocking stuff can be solved with true async file i/o support (via direct kernel support or kernel threads) and good old forking (preforked backend blocking servers and doing comm with either pipes or shared ram). you just have to think outside the threaded box.
I've written plenty of async I/O with event loops, etc, and yes, it does work very fast and efficiency. (and yes, Parrot absolutely needs async I/O). However, I generally view it as a major pain in the rump, and it seriously obscures what it going on, especially if you have some radically different things going on at once. Much clearer to read code that dispatches a thread that can block. This is likely one of the reasons it gets promoted as a "Good Idea".
I've also encountered things that had some reasonable issues solving that way. Example of logical flow of actions:
For several different sites,
1) Grab one or more sets of data over the net. (can be heavily lagged)
2) Munch the data grabbed, something that can be very intensive.
3) If errors were found (data incomplete), put the page back in the queue and go back to 1.
4) Otherwise, start feeding processed data into a Database (can also block on overloaded DBs).
What's the problem with doing this in an event loop? Step 2. I've had times where this was intensive enough that Step 1 happening for other sites were dropping tcp connections. Forking didn't work well, because I needed to mark things as done/not done back in the main loop.
Breaking step 2 into smaller pieces that played nice wasn't feasible, so I went to a forking model w/ IPC. 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.
just plugging events,
Events are good. But they are not a complete replacement for threads. Just like threads are not a complete replacement for event loops.
IMO, parrot should be able to support both models strongly, and not overly promote one over the other.
-- Rod
