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 E378DBBA7 for ; Tue, 7 Feb 2006 22:31:48 +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 k17LVmr0008483 for ; Tue, 7 Feb 2006 22:31:48 +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 WAA26697 for ; Tue, 7 Feb 2006 22:31:47 +0100 (MET) Received: from mailscan1.sslisp.com (lb.sslisp.com [209.213.12.74]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k17LVkCK008148 for ; Tue, 7 Feb 2006 22:31:47 +0100 Received: from [192.168.0.99] (68-186-66-70.dhcp.knwk.wa.charter.com [68.186.66.70]) by mailscan1.sslisp.com (Vircom SMTPRS 4.2.425.16) with ESMTP id for ; Tue, 7 Feb 2006 13:30:08 -0800 X-Modus-ReverseDNS: OK X-Modus-BlackList: 68.186.66.70=OK;rick@eltopia.com=OK X-Modus-RBL: 68.186.66.70=OK X-Modus-Trusted: 68.186.66.70=NO Subject: Re: [Caml-list] Re: async networking From: Rick Richardson Reply-To: rick@eltopia.com To: 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 Organization: Eltopia Date: Tue, 07 Feb 2006 13:29:35 -0800 Message-Id: <1139347775.10092.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 43E911C4.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43E911C2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 async:01 argg:01 threads:01 threads:01 api:01 buffer:01 cheers:01 juncture:98 wrote:01 wrote:01 invert:01 thread:02 data:02 callback:02 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 Tue, 2006-02-07 at 18:44 +0100, Bardur Arantsson wrote: > 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. My only interest lies in high performance networking, specifically in a high connection / low data volume scenario (at this juncture at least). The optimal solution is some form of iocp with multiple threads (1 per open socket initiated at startup). I think at some level of high performance networking the whole file analogy goes out the window. The multiple serving threads could actually make for an simple api, actually. A simple function to add a receive callback for a port would be all you'd need. You could even pass in a buffer to that callback that a person could respond directly to for socket send, since the same thread is handling the send requests as well. > > Point #2: It is not customary for UI applications to require > particularly high-performance I/O, thus rendering the non-composability > issue moot. > > I'm _not_ recommending libevent for general use, just if you want high > performance with an easily switchable backend implementation. > > Cheers, >