Concurrency for services

[Christophe TROESTLER <Christophe.Troestler@umh.ac.be>]

Hi,

I have been confronted a couple of times to the following situation
and I am looking for advice for a good (the best, if possible :)
reusable solution.

Imagine you want to build a server library (e.g. a Lpd daemon, a file
server, a web service,...).  In broad terms, you can describe it as a
protocol for which you will handle the various "events" by callbacks.
You do not want to wire any concurrency model in your library but
instead provide the user with the appropriate functions so it can use
his favorite concurrency schema.  My question is: what is the best way
to do that?

Perhaps naively, I am thinking along these lines.  There are three
points where a possibility of concurrency naturally offers itself:

1. several threads/processes can listen (run "accept") on the same
   socket;

2. each time a connection is accepted, one may decide to process it in
   a new thread/process (or send it to a pool of threads/processes,...);

3. each time one calls a callback (that only makes sense if several
   callbacks can be called independently for a single connection).

It seems to me that 3. belongs to the design of the library and cannot
easily be abstracted.  1. and 2. however are basically the same from
one library to the next.  For 2., one has to distinguish whether one
uses threads of processes to know when the accept socket has to be
closed.  So one ends up with 3 functions:

val socket : unit -> Unix.file_descr
val accept_fork :
  fork:((Unix.file_descr -> unit) -> int * Unix.file_descr) ->
  'a connection_handler -> Unix.inet_addr -> unit
val accept_threads :
  ?thread:((unit -> unit) -> unit) ->
  'a connection_handler -> Unix.inet_addr -> unit

The [connection_handler] is an abstract type that is created by a
[handle_connection] which states which callback(s) to use.  The file
descriptor in [fork] is a communication channel for the son to send
messages to the father (the father may need to react to some commands
in the protocol e.g. "shutdown").  A simple usage is

let () = accept_threads (handle_connection f) (socket())

Of course, there usually will be many optional arguments to tailor the
behavior of these functions.  I wonder:

i. are the above functions able to take care of about any concurrency
   model one can imagine (new thread/process, pool of threads,
   dispatching to a set of machines,...);

ii. are they designed well enough so that they can form a signature on
    which one can build usual concurrency models through functors?

I do not have a large experience with concurrency models, so your
input is very much appreciated.

Regards,
ChriS