From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA14085; Thu, 12 Jul 2001 22:58:58 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA14019 for ; Thu, 12 Jul 2001 22:58:57 +0200 (MET DST) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6CKwun13267 for ; Thu, 12 Jul 2001 22:58:56 +0200 (MET DST) Received: from [195.20.224.208] (helo=mrvdom01.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 15KnY0-00075t-00 for caml-list@inria.fr; Thu, 12 Jul 2001 22:58:56 +0200 Received: from drms-3e3653b9.pool.mediaways.net ([62.54.83.185] helo=ice.gerd-stolpmann.de) by mrvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 15KnXz-0006n8-00 for caml-list@inria.fr; Thu, 12 Jul 2001 22:58:55 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id WAA07268 for caml-list@inria.fr; Thu, 12 Jul 2001 22:58:31 +0200 From: Gerd Stolpmann Reply-To: info@gerd-stolpmann.de Organization: privat To: caml-list@inria.fr Subject: Re: [Caml-list] High level (asynchronous) networking library? Date: Thu, 12 Jul 2001 22:37:52 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01071222582913.00523@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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