[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.)




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.