Joel VanderWerf <vjoel / path.berkeley.edu> writes: >> Blocking IO can occasionally cause unexpected problems. >> For example, in some cases a blocking read *can* block even >> though select said that the file descriptor was readable. >> This problem may be rare (it can happen, for instance, when >> the checksum of a piece of data fails to match the payload), >> but the bottom line is that non-blocking IO is safer. > > Well, at least in recent linux 2.4 and 2.6 kernels, this > particular problem is fixed (see the recent ruby-talk > discussion entitled "event driven framework for ruby", > particularly comments by Akira Tanaka and Ralf Horstmann). Hmm, okay, then I guess I shall have to remove or annotate that paragraph to avoid spreading FUD. >> Perhaps most importantly, while Ruby's threads are green, >> they are still effectively preemptively scheduled, with all >> the implications thereof ¡½ in a word, synchronization hell. >> By contrast, event handlers are executed in a strictly >> sequential manner; an event loop will never run two event >> handlers simultaneously. (Though, of course, all bets are >> off if you run multiple event loops in separate threads.) > > But in some cases you *want* preemptive scheduling. Sure. If I want preemptive scheduling, I use threads. Sometimes, I don't even have a choice. (Ruby's GNU Readline wrapper only supports blocking calls, for instance.) > One handler's execution shouldn't block the others, if it > might take a significant time to finish. Event handlers should not take a significant amount of time to finish. If they do, you have coded them wrong. :-) > Take care of synchronization with concurrent data > structures like queues, or if that isn't sufficient, lower > level mechanisms like mutexes. Or use a deterministic event loop and avoid the problem of synchronization altogether. In a callback-based system, you have to deal with callbacks. In a preemptively multithreaded system, you have to deal with synchronization. It's a tradeoff, and largely a matter of taste, preference and familiarity. You might also ask yourself, do you really *need* to have the scheduler arbitrarily switch contexts back and forth? Do your event handlers really take that much time to run? If so, fine. Otherwise, why not have determinism instead? -- Daniel Brockman <daniel / brockman.se>