From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 07A55BBAF for ; Fri, 16 Jul 2010 18:18:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIBAKkiQEzRVaG0mGdsb2JhbACDH5xDCBUBAQEBAQgJDAcRIq4mO4IPhWcuiFMBAQMFgwcBgSVyBIN+hFI X-IronPort-AV: E=Sophos;i="4.55,215,1278280800"; d="scan'208";a="66554781" Received: from mail-gx0-f180.google.com ([209.85.161.180]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Jul 2010 18:18:28 +0200 Received: by gxk22 with SMTP id 22so1774430gxk.39 for ; Fri, 16 Jul 2010 09:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=j7Ci07ICTPq1xmYOnFs/OQVf2+0Z48fVf+84gHF1V7I=; b=PcaHqkOj98/eyxuQ2XghheGgsQbbwI+S4Wx3u6A04+6kWgzVoHtHaoin92rkp/PxXe yQ/46MU/EQHGs+e+ZqxwxzIUinqBffXLE3FMPpkBlw1npgIOKqS5iM7ShB9AJ5A+RBCj BcNlm/0+rjG09SnuCCITT/jWzaD/Uj5N9iZcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nfn281JUldOauthSU4OjPhmVBZrfa/pMjkKGb4FHXpK6SckvV6wURoLKsI1KTPhFLQ 8LHSoX/GGXwG6Fgzuu1JfVRU/UW+xD83dRaJwzs8d2C51SyD4vbxf4BNyK63bi5nnkjP +Q13pkivwfB3Sjje1j40WNGiIIZWFqARnZN5U= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr404571anf.117.1279297106944; Fri, 16 Jul 2010 09:18:26 -0700 (PDT) Received: by 10.100.212.6 with HTTP; Fri, 16 Jul 2010 09:18:26 -0700 (PDT) In-Reply-To: <87630fbmvb.fsf@frosties.localdomain> References: <87sk3mcaeq.fsf@frosties.localdomain> <87zkxsfvsg.fsf@frosties.localdomain> <87hbk0vzut.fsf@frosties.localdomain> <87630fbmvb.fsf@frosties.localdomain> Date: Fri, 16 Jul 2010 11:18:26 -0500 Message-ID: Subject: Re: [Caml-list] Smart ways to implement worker threads From: Rich Neswold To: Goswin von Brederlow Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016e64f8f4a9f3bdf048b839121 X-Spam: no; 0.00; bookkeeping:01 mutexes:01 ocaml:01 bookkeeping:01 mutexes:01 ocaml:01 protects:98 protects:98 threads:01 wrote:01 wrote:01 caml-list:01 exceptions:01 exceptions:01 modules:02 X-Attachments: cset="UTF-8" cset="UTF-8" --0016e64f8f4a9f3bdf048b839121 Content-Type: text/plain; charset=UTF-8 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 --0016e64f8f4a9f3bdf048b839121 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 16, 2010 at 8:02 AM, Goswin von Brederlow <= ;goswin-v-b@web.de> wrot= e:
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 wit= h them. You must make sure your unlocks match your locks -- even in the pre= sence of exceptions. None of this bookkeeping is required from the programm= er when using Event.

The bigger win for Events, though, is that they're = composable.

Let's say you decide to have two q= ueues to communicate with two workers. With the mutex/queue=C2=A0scenario, = you'd have to resort to polling each queue -- locking and unlocking eac= h 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.ch= oose' 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 t= he list is enough. Granted, if you mix and match event types (sends and rec= eives, 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 mod= ule.
=C2=A0
--
Rich

Google Reader: https://www.google.com/reader/s= hared/rich.neswold
Jabber ID: rich@neswold.homeunix.net
--0016e64f8f4a9f3bdf048b839121--