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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 1BA1BBBA7 for ; Tue, 7 Feb 2006 20:01:12 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k17J1BKW020343 for ; Tue, 7 Feb 2006 20:01:11 +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 UAA24163 for ; Tue, 7 Feb 2006 20:01:11 +0100 (MET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k17J1A54020340 for ; Tue, 7 Feb 2006 20:01:10 +0100 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1F6Y5N-0008TH-00; Tue, 07 Feb 2006 20:01:09 +0100 Received: from [84.58.144.163] (helo=gate.lan.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1F6Y5N-00013O-00; Tue, 07 Feb 2006 20:01:09 +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 2E47AC178; Tue, 7 Feb 2006 20:01:09 +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> Content-Type: text/plain Date: Tue, 07 Feb 2006 20:01:08 +0100 Message-Id: <1139338868.12287.185.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 concorde with ID 43E8EE77.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43E8EE76.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 argg:01 labltk:01 lablgtk:01 lablgtk:01 latency:01 descriptors:01 descriptors:01 sockets:01 latency:01 gerd:01 cheers: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, 18:44 +0100 schrieb Bardur Arantsson: > skaller wrote: > > On Mon, 2006-02-06 at 19:34 +0100, Bardur Arantsson wrote: > > > >> However, if you want very high-performance networking > >> you'd be better off with something closer to the metal, i.e. something > >> like a libevent wrapper > > > > Argg no. Libevent isn't a library, it doesn't control invert. > > It is a monolithic framework. Therefore it is not very useful because > > your code will no longer be composable. In particular, > > there is no way to compose two such frameworks, for example > > you cannot use it with an event driven GUI framework. > > > > Note that I said 'high-performance'. > > Point #1: select() and anything based on it (I believe Equeue still is > though I haven't looked at it for quite a while) is woefully inadequate > for high performance I/O except in very specific circumstances. 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. Or one that sits upon libevent. There is, however, the basic design decision that all events pass the same queue. This mainly has a certain scheduling effect (application-driven scheduling), and increases latency if the queue gets too long, but shows good behaviour under high load. 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. > Point #2: It is not customary for UI applications to require > particularly high-performance I/O, thus rendering the non-composability > issue moot. There are many aspects of high performance, for example throughput, latency, and whether a low or high number of descriptors are watched. UI applications are often interested in low latency for a moderate number of descriptors. 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. For example, an HTTP component is useful for both, so why should we develop an extra one for specific needs of high performance? Gerd > I'm _not_ recommending libevent for general use, just if you want high > performance with an easily switchable backend implementation. > > Cheers, > -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Telefon: 06151/153855 Telefax: 06151/997714 ------------------------------------------------------------