Re: [Caml-list] Smart ways to implement worker threads

[Rich Neswold <rich.neswold@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Fri, Jul 16, 2010 at 8:02 AM, Goswin von Brederlow <goswin-v-b@web.de>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

[-- Attachment #2: Type: text/html, Size: 2091 bytes --]