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

Daniel Brockman wrote:
> 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?

That's a good point.

I do like what using threads does to the architecture of my program.
It's very easy to separate all the functionality out into components,
each of which performs a specific task, has a ThreadGroup to manage its
own threads, and communicates with other components by queues. The
components can be tested idependently and even executed in other
processes/hosts, if you replace Queue with something based on Sockets
and Marshal, or DRb.

So I guess another consideration in making this tradeoff is the degree
to which the system as a whole can be decoupled.

If, for example, the handlers are making atomic updates to some
monolithic data structure, or to a GUI, then decoupling doesn't make
sense: the overhead to make the updates atomic would be too high.

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