Bogdan Costescu <[EMAIL PROTECTED]> writes: > On Wed, 2 Jul 2008, Perry E. Metzger wrote: > >> Event driven programming typically uses registered callbacks that >> are triggered by a central "Event Loop" when events happen. In such >> a system, one never blocks for anything -- all activity is performed >> in callbacks, and one simply returns from a callback if one can't >> proceed further. > > And here is one of the problems that event driven programming can't > really solve: separation between the central event loop and the code > to run when events happen.
I don't understand what you mean. > fork() allows the newly created process to proceed at its own will > and possibly doing its own mistakes (like buffer overflows) in its > own address space - the parent process is not affected in any way > and this allows f.e. daemons to run their core loop with > administrative priviledges while the real work can be done as a dumb > user. Oh, that's not an issue at all. For example, say you wanted to run an SMTP daemon as a pure event app but you don't want it to run as root. So, you're screwed because you can't open port 25 as a normal user, right? Well, you can either change privs after opening 25, or you can use fd passing to pass open file descriptors between a small rootly process and the mail processing event driven process. Anyway, yah, bugs are a problem. If you have a bug in an event driven system you bring down 10,000 connections at once instead of 1. You do indeed have to be confident your code doesn't suck. -- Perry E. Metzger [EMAIL PROTECTED] _______________________________________________ Beowulf mailing list, [email protected] To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
