On Fri, Jul 16, 2010 at 8:02 AM, Goswin von Brederlow wrote: > Yeah. But then why not build it around the simple Mutex and Condition > modules instead of Event? At first glance the blocking aspect of Events > seem to be more of a hindrance than help. > The problem with Mutex and Condition is all the management that goes with them. You must make sure your unlocks match your locks -- even in the presence of exceptions. None of this bookkeeping is required from the programmer when using Event. The bigger win for Events, though, is that they're composable. Let's say you decide to have two queues to communicate with two workers. With the mutex/queue scenario, you'd have to resort to polling each queue -- locking and unlocking each mutex in turn (or decide that a single mutex protects both queues ... but this approach doesn't scale well.) With events, you pass a list of events to 'Event.choose' and the process will be awakened when one of the events returns a value. No need to widen the protection of mutexes; adding more events to the list is enough. Granted, if you mix and match event types (sends and receives, for instance) you may have to use 'Event.wrap' to make sure they return a compatible type. Event may not be the best solution for your problem, or it may even lie outside your comfort zone. Hopefully this discussion has, at the very least, made some OCaml users take another look at the Event module. -- Rich Google Reader: https://www.google.com/reader/shared/rich.neswold Jabber ID: rich@neswold.homeunix.net