From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id A45ADBB83 for ; Sat, 19 Aug 2006 11:42:25 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7J9gPgC022780 for ; Sat, 19 Aug 2006 11:42:25 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA09896 for ; Sat, 19 Aug 2006 11:42:24 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7J9gMkX022765 for ; Sat, 19 Aug 2006 11:42:23 +0200 Received: from rosella (ppp14-47.lns2.syd7.internode.on.net [59.167.14.47]) by smtp3.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k7J9fpIV023175; Sat, 19 Aug 2006 19:12:02 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Re: Help interfacing with C From: skaller To: Richard Jones Cc: Nathaniel Gray , Bardur Arantsson , caml-list@inria.fr In-Reply-To: <20060819090319.GA2213@furbychan.cocan.org> References: <20060819090319.GA2213@furbychan.cocan.org> Content-Type: text/plain Date: Sat, 19 Aug 2006 19:41:51 +1000 Message-Id: <1155980511.29567.24.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; interfacing:01 ocaml:01 gerd:01 threads:01 bytecode:01 config:01 callbacks:01 stack:01 translating:01 model:01 model:01 haskell:01 ocaml:01 bytecode:01 stack:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Sat, 2006-08-19 at 10:03 +0100, Richard Jones wrote: > It sounds also like you shouldn't use select at all, but consider some > of the more modern alternatives. Here is a good place to start: > > http://www.kegel.com/c10k.html#nb.select Yeah but if you were doing that you'd probably want to use the demux library which is part of Felix .. in which case you'd want to use it as part of the context switching too .. in which case you might was well just use Felix instead of Ocaml :) I'd be thinking of Equeue if you do want to use 'modern' alternatives, since it has generic support for different notification methods: looks like you could use a select binding, and switch to some other method later if you weren't happy with the performance. Perhaps Gerd can confirm this? Felix chooses the best of: epoll, kqueue, poll, windows IOcompletion ports, Solaris iocompletion ports, and select and abstracts the lot away. The end user just does blocking I/O .. but it only blocks fibres, not threads (unless there is nothing ready of course). [Doesn't the VMthreads of bytecode do this too?] The difficulty getting this right should not be underestimated. For example, epoll is available in Linux 2.4 but it doesn't work: the config script actually has to call it to find out it is dysfunctional. Felix outperforms C10K by at least 2 decimal orders of magnitude, without resorting to callbacks, and without assembler hacks like stack swapping. It does this by *translating* code using a thread model into code using a callback model. The demux library demultiplexes notifications and hooks the results into the scheduling algorithm. I believe both Haskell and MLton can do this kind of thing too (though I'm not sure): continuation passing is essential. I don't think Ocaml uses continuation passing, however most bytecode interpreters do (including for example Python) because it's the only way to write a bytecode interpreter :) Felix uses heaped continuations for procedures, but the stack for functions.. a fairly novel and rather ugly mix (required for C compatibility .. and also yielding the best performance). All these systems, either implicitly or, now in the case of Felix quite explicitly .. are replacing poor operating system designs like Unix. You have to remember Unix was designed for batch processes with some time sharing: its hardly surprising it doesn't work well with threads and real time events .. it was designed to isolate the end user from these features! -- John Skaller Felix, successor to C++: http://felix.sf.net