Re: [Caml-list] Master-slave architecture behind an ocsigen server.

[Alain Frisch <alain@xxxxxxxxx>]

On 03/28/2013 12:02 PM, Anil Madhavapeddy wrote:
> Are all of the messages through these queues persistent, or just the larger 
> ones that are too big to fit in the shared memory segment, and are they always 
> point-to-point streams?
The messages always go through shared memory queues (non persistent), 
but their payload is offloaded to the file system (in temporary files) 
when it is too large.  There is no real persistence, though, because the 
temporary file is not self-describing (it is not sufficient to restart a 
computation after a process failure, for instance).  (The distribution 
of computations through a database is closer to real persistence.)
Queues are unidirectional point-to-point streams between two processes 
(we use a pair of such queues for between the main process and the 
scheduler, and between the scheduler and each worker process).
The relevant part of the API is:

========================================================
type t
      (** The type of point-to-point shared memory queues. *)

val create: ?max_size:int -> unit -> t
    (** A queue is created in one process with [create], passed by
        name (using [id]) to a single another process which can call
        [from_id]. *)

val from_id:  ?max_size:int -> string -> t
    (** Access a queue created by another process given its unique
        name. *)

val id: t -> string
    (** Globally (system-wide) unique name attached to the queue. *)

val close: t -> unit

exception CannotGrow
exception BrokenPipe

val send: t -> string -> unit
    (** Non-blocking operation.
        Raises [BrokenPipe] if the reader has disconnected.
        Raises [CannotGrow] if the maximum size of the buffer has been 
reached. *)
val read: t -> string option
    (** Non-blocking operation.
        Returns [None] if no message is available.
        Raises [BrokenPipe] if the writer has disconnected. *)
========================================================

If there is some interest for it, maybe Fabrice could release the code 
with an open source license?
One thing which is not supported by this library is a notification 
mechanism to inform the other side of the queue that messages are 
available.  For now, we simulate that by pinging the processes 
stdin/stdout descriptors.  In the scheduler and the worker, we use 
select to monitor them (there is probably a big cost of doing so, 
especially considering how select is emulated under Windows).  In the 
GUI process, we use standard .Net process monitoring facilities to 
inject callbacks in the main GUI thread.  (The OCaml side of our 
application in mono-threaded, and we use a few external native or .Net 
threads to monitor system conditions.)

Alain