From: Joel VanderWerf <vjoel@...>
Date: 2005-08-26T02:16:13+09:00
Subject: Re: [ANN] EventLoop 0.0.20050825.1600

Daniel Brockman wrote:

> First of all, you may consider the event loop API more
> pleasant than Ruby's threads and not-quite-blocking IO.
> Otherwise, don't listen to me; go on using the latter. :-)

I *love* ruby threads. Still, I wish ruby's thread scheduler would
handle more types of blocking than select can handle, such as waiting
for a file lock.

> 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).

> 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. One handler's
execution shouldn't block the others, if it might take a significant
time to finish. Take care of synchronization with concurrent data
structures like queues, or if that isn't sufficient, lower level
mechanisms like mutexes.

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407