On Thu, 12 Jul 2001, you wrote:
>I've been learning O'Caml for the past little bit, and after not finding any 
>high level asynchronous networking libraries (that is, libraries/modules for 
>writing high performance network servers), I figured I would write one, 
>since it seemed a non-trivial problem that wasn't too far out of my league.

You may have a look at Equeue:
http://www.ocaml-programming.de/packages/documentation/equeue/manual/

It implements an event queue, and you can attach "event sources" (such as file
descriptors) and event handlers. Because it is a queue, it is not very fast if
there are many events at the same time.

You may also look at my RPC implementation:
http://test.ocaml-programming.de/packages/documentation/rpc/

It bases on Equeue, and is an excellent example.

>Anyway, I've been looking at possible ways to write one.  In Python, I've 
>made quite a bit of use of the "asyncore" module 
>(http://www.nightmare.org/medusa/index.html), which is a very production 
>proven (it's the asynchronous networking engine used in Zope) and simple 
>framework for writing high performance asynchronous servers.  It seems that 
>implementing asyncore in O'Caml would be fairly straightforward, so I've 
>been putting it off a bit while I search for a possibly better solution.

The link does not work.

>Someone has written "asyncore turned inside out" using Stackless Python, an 
>implementation of Python that has first-class continuations) using 
>continuations to implement the apparent multi-tasking.  It apparently (I've 
>not used it myself) makes the asynchronous networking part of the coding a 
>little more transparent to the user than asyncore does.  I'm curious if 
>something similar could be implemented in O'Caml with closures, and if it 
>could achieve similar user-transparency.

You could do something like

let task1 arg cont =
  let before_call () = ... in
  let after_call () = ... in
  before_call();
  task2 arg' (fun () -> cont(); after_call())

(task2 in a similar way). "cont" is the function that continues. The problem is
that this scheme needs much memory, as every task switch allocates a new
closure. When the closure is evaluated, some stack space is needed, too, so
after some time there will be lots of half-evaluated closures, and a stack
overflow is very likely.

>Does anyone have any comments on any of the above options?  Are there other 
>options I'm not considering which could be better?  Are there any 
>implementations of what I want already?  What I'm looking for is as much 
>abstraction away from the low-level socket/select loops as is reasonable for 
>efficiency's sake.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr