>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
> 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. other than the fork issue on win32, it can be done with events. i have layered an async/sync flow control module over an event loop. it allows remote (blocking or heavy crunching ops) to be mixed with local ops in a simple if/then/while minilang. it removes much of the state issues from complex event loops. ask me about it off list if you want more on that. i even sent leo (though i am not sure of ownership since that company went under) a generic event loop in c that i wrote. even if it can't be used for legal or technical reasons, it should be useful to him and dan for its design ideas and speed. it uses doubly linked queues (with a full public api of its own and a slab malloc similar to what parrot has) to handle all the event types (read/write/timer/signal/plain). dan's plan is to put the single event loop into a single kernel thread and have a event and trigger queues shared by all threads (parrot or kernel). so my event loop design and/or code could be used there. and i also did run that application with kernel (solaris actually) threads for blocking ops (dns lookups) and the event loop in one process. it used a pipe to itself to sync the dns worker threads with the main thread which ran the event loop. so you can use both in one design if you integrate them properly. the pipe was an elegant synch solution as you can put an event handler on one side and the threads could do blocking reads on the other side. all that was written on the pipe was the address of a command block (for the dns and its results). i haven't see many systems which have a process use a pipe to itself :) > Events are good. But they are not a complete replacement for > threads. Just like threads are not a complete replacement for event > loops. i totally agree. it is just that threads get way more publicity than event loops. i am just trying to balance that here. :) you have to realize i have been doing event loop systems for over 20 years (i have created at least 4 different major event systems in very different environments) so events come very naturally to me. they seem to be trickier for some and they gravitate to threads which is a 'simpler' model but as i have said has its own pitfalls and efficiency issues that few typical thread users recognize. > 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. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
