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 5BA29BBA7 for ; Tue, 7 Feb 2006 21:30:32 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k17KUVql001576 for ; Tue, 7 Feb 2006 21:30:31 +0100 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 VAA25032 for ; Tue, 7 Feb 2006 21:30:31 +0100 (MET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k17KUUjj029827 for ; Tue, 7 Feb 2006 21:30:31 +0100 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1F6ZTq-0000VK-00; Tue, 07 Feb 2006 21:30:30 +0100 Received: from [84.58.144.163] (helo=gate.lan.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1F6ZTq-0002FT-00; Tue, 07 Feb 2006 21:30:30 +0100 Received: from flakew.lan.gerd-stolpmann.de (flakew.lan.gerd-stolpmann.de [192.168.0.32]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 221FDC178; Tue, 7 Feb 2006 21:30:30 +0100 (CET) Subject: Re: [Caml-list] Re: async networking From: Gerd Stolpmann To: Bardur Arantsson Cc: caml-list@inria.fr In-Reply-To: References: <1139129530.15565.3.camel@localhost.localdomain> <1139160736.10812.3.camel@localhost.localdomain> <1139288125.19213.36.camel@rosella> <1139338868.12287.185.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 07 Feb 2006 21:30:29 +0100 Message-Id: <1139344229.12287.207.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at nez-perce with ID 43E90367.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43E90366.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 async:01 gerd:01 stolpmann:01 labltk:01 lablgtk:01 lablgtk:01 descriptors:01 descriptors:01 sockets:01 invocation:01 ocaml:01 allocations:01 iteration:01 latency: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.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 Am Dienstag, den 07.02.2006, 20:43 +0100 schrieb Bardur Arantsson: > > Yes, the default Equeue implementation bases simply on select(). It is, > > however, possible to develop alternate implementations. Currently, there > > are three of them which integrate into the event loops of labltk, > > lablgtk1 and lablgtk2. One could, for example, easily add an > > implementation for advanced kernel interfaces like epoll. > > Actually, it might be quite interesting to see one based on > poll()/epoll(), but I suspect it wouldn't matter much compared to all > the other stuff that's going in the Equeue code. This is just a very > vague hunch, though. The Equeue core is quite light-weight, there are just some modules on top of it that make life easier at the user's option. So it would matter. > > select() is, as far as I know, only bad if the file descriptors are > > linked with many different processes, because all that processes must be > > waked up in order to check the descriptors (even if no I/O can happen). > > But if you only have Internet sockets, I expect that select() performs > > well. > > There are lots of problems with select(). For example, it generally > requires copying the file descriptor sets from user-space to kernel > space for every select() invocation, the scanning of active file > descriptors afterward can be inefficient(*), from OCaml it also causes > more pressure on the GC through list allocations for result sets, etc. etc. That depends all very much on the average data case. E.g. if all the descriptors generate events at the same time, there is nothing bad with select(). If the typical case is that only very few descriptors "fire" it has very much overhead. The poll() interface fixes a number of these issues. Anyway, in practice it is not much better than select() just because it is also based on passive iteration. One needs an actively notifying interface to improve that. > Sure, but not at the level I'm talking. I'm talking about saturating > high-bandwidth links, ultra-low latency -- though usually not at the > same time, obviously ;). You know, the kind of stuff you might even > consider using C/C++ (shudder) for just to avoid GC. Given that data also needs to be processed by the application, it would be quite interesting whether the choice of the language makes a difference here. I would guess the time for GC can be kept low in relation to the costs for context switches, even for the high-performance case. And in O'Caml one can prefer to program in a style that reduces the load on the GC. A much nicer alternative than considering C/C++ too early. > > I think there is another point why it is a bad idea to distinguish > > between, say UI and server applications. Network components should be > > shareable between all types of applications. > > Yup. Though all non-blocking I/O has the basic problem of "one event > loop to rule them all" unless you go with several threads, each running > their own event loop... At which point you might as well have each of > those components just using regular blocking I/O and using threads as > appropriate. Note, I'm not talking about performance characteristics > here, just design. Also, exception handling and such can be handled much > more nicely with a threaded design since they don't "invert" the control > logic the same way non-blocking I/O tends to do. Really? From my experience I would say that exception handling is much easier in the non-blocking case. Exceptions may raise complicated synchronisation issues in the threaded design. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Telefon: 06151/153855 Telefax: 06151/997714 ------------------------------------------------------------