Re: [Caml-list] Concurrency for services

[John Skaller <skaller@users.sourceforge.net>]

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

On Wed, 2005-07-13 at 00:40 +0200, Christophe TROESTLER wrote:
> Hi,

> 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?

The way the Felix model handles that is:

(a) The code is represented by a library which 'reads' 
abstract events of some type determined by the library.

(b) The programmer who is the client of this library
is responsible for all scheduling, threading, and  I/O.

That is, the library leaves the I/O and scheduling
"up to the operating system" which the client programmer
is required to write.

A twist with the Felix model is that the code is written
with 'read' commands, but the Felix translator control
inverts (twists) the code into event driven code.

Actually a version for Ocaml is possible although I
haven't tried to create one yet -- Felix targets C++
but it should work for any language which supports
classes with virtual functions and switches.

[Anyone want to take on an Ocaml back end?]

The system generates a class with a 'resume()' method
which looks like this in C++

con_t *resume() {
  switch (pc) {
    case 1: ....

          // read variable is translated to this:
          read=true;            // flag we need an event
          read_ptr = &variable; // where to deliver it
          pc = 2;               // set return address
          return this;
    case 2: ....

  }
}

An ocaml version would look the same. The point is that the 
library code incorporates all the abstract business logic,
protocol rules etc, but leaves out all the physical I/O
and timing issues.

I would love to recommend examining Felix package,
however there aren't any good examples yet. 

It was originally designed to run with an existing C++ framework
using ACE, ACN, TCAP, and other telephony stuff --
a million lines of C++ code -- where it provided the
'business logic' required by each client (a client
being a national telecoms carrier).

Examples of business logic rules include 1800,
911, prepaid, conference, and other telephony
services and 'products' offered by the client.

In this case the processing model used included
setting up a database server, plus a multi-CPU
Solaris box with a worker thread per CPU, plus
a collection of threads to do the event collation,
I/O, database caching, load balancing, etc etc etc.


-- 
John Skaller <skaller at users dot sourceforge dot net>
Download Felix: http://felix.sf.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]