Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: "Milan Stanojević" <milanst@gmail.com>
Cc: yminsky@gmail.com, caml-list@inria.fr
Subject: Re: [Caml-list] [ANN] Async, a monadic concurrency library
Date: Thu, 27 Oct 2011 20:34:07 +0200	[thread overview]
Message-ID: <1319740447.18639.220.camel@thinkpad> (raw)
In-Reply-To: <CAKR7PS9Z86WEFaveURvEposEPKDfqx=Tvt04xM6S61SS54S+vQ@mail.gmail.com>

Am Donnerstag, den 27.10.2011, 13:36 -0400 schrieb Milan Stanojević:
> >>  But I think we had good reasons for creating Async.  As I said in my
> >> blog post, the differences in error-handling and interleaving policy
> >> were enough that we really felt we needed a different library.
> >
> > In deed this is interesting. Equeue also follows Lwt's idea not to
> > interleave when possible, simply for performance reasons. You can,
> 
> Did you mean to say "Lwt interleaves when possible"?
> 
> For example
> 
> let foo () =
>     let r = x >>= bar in
>     ....
>      r
> 
> in Async [bar] will run only after [foo] has completed (therefore
> there is no interleaving between [foo] and [bar]), while in Lwt [bar]
> can run in the middle of [foo] so there is an interleaving

You probably mean the case where x has already computed a result.

When developing Uq_engines, I was a bit unsure how to treat this case.
In the initial version, I just disallowed this case: There was simply no
way to run into it. If you wanted to create a thread that just yields a
constant value, the only way was the function eps_e, which "computes"
the constant in one step (i.e. it is not immediately there, but only
after rescheduling). Later I allowed this case, and also added const_e,
which creates a thread with an immediate result.

Nevertheless, almost all code I produced uses eps_e, not const_e,
because the possible interactions with state changes are easier to
overlook. However, there is also const_e when speed really matters.

Besides this problem, I'm unsure where the other conceptual differences
are between the threading implementation. For example, Equeue has
actually two schedulers: one very simple one, which is only used when no
I/O and no delays need to be considered (and which is local to
Uq_engines), and a heavy one when these phenomenons can occur. The
simple scheduler is really unfair - the next thread at hand is executed,
often leading to a cache-friendly execution flow with high locality. But
it's fast. The other scheduler is absolutely fair: all resources are
treated equal, and events are queued up (fifo order). It is only invoked
when the simple scheduler cannot continue.

So yes, there are probably differences. I am a bit surprised that Equeue
(which is part of Ocamlnet, btw) is not recognized as monadic threading
library, although it was definitely the first public Ocaml library
exploring this idea (beginnings in 1999), and has probably the largest
user code base (remember the original wink.com search service was
written with it). It was "only" never been announced as monadic, and
uses a different terminology because it's a threading library in the
first place, and I always hoped it's easier to understand for people
without Haskell background.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------



  reply	other threads:[~2011-10-27 18:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-26  0:32 Yaron Minsky
2011-10-26  5:31 ` Cedric Cellier
2011-10-26 10:40   ` Yaron Minsky
2011-10-26  7:33 ` Gerd Stolpmann
2011-10-26 10:57   ` Yaron Minsky
2011-10-26 11:18     ` rixed
2011-10-26 11:34       ` Yaron Minsky
2011-10-26 12:49         ` Jérémie Dimino
2011-10-26 12:31     ` Gerd Stolpmann
2011-10-27 17:36       ` Milan Stanojević
2011-10-27 18:34         ` Gerd Stolpmann [this message]
2011-10-27 19:10           ` Milan Stanojević
2011-10-28  7:29             ` Gerd Stolpmann
2011-10-26  8:07 ` Jérémie Dimino
2011-10-26 11:03   ` Yaron Minsky
2011-10-26 11:06     ` Mark Shinwell
2011-10-26 11:20       ` Anil Madhavapeddy
2011-10-26 11:37         ` Mark Shinwell
2011-10-29  0:52       ` oliver
2011-10-31  9:12         ` Mark Shinwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1319740447.18639.220.camel@thinkpad \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=milanst@gmail.com \
    --cc=yminsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox