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 5AE48BBA7 for ; Tue, 7 Feb 2006 20:28:11 +0100 (CET) Received: from mailscan2.sslisp.com (lb.sslisp.com [209.213.12.74]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k17JS9KT023071 for ; Tue, 7 Feb 2006 20:28:10 +0100 Received: from [192.168.0.99] (68-186-66-70.dhcp.knwk.wa.charter.com [68.186.66.70]) by mailscan2.sslisp.com (Vircom SMTPRS 4.2.425.16) with ESMTP id for ; Tue, 7 Feb 2006 10:44:57 -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 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 10:44:54 -0800 Message-Id: <1139337894.24817.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43E8F4C9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 async:01 buffer:01 overkill:01 ocaml:01 callback:02 scope:02 library:03 quite:06 standard:07 seem:07 rather:07 rendering:08 i'm:08 haven't:08 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,SPF_SOFTFAIL autolearn=disabled version=3.0.3 > 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. > I was planning on a select() based system. Which architecture would you recommend? I like the idea of the ring buffer. Especially for switch type applications which are going in one port and out the other. For a standard system that could involve 2-3 different copies when 1 would be adequate. > 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. I haven't fully looked at the libevent system, but any such framework would seem like overkill to me, when really I just need a lightweight "deferred" class which maintains a simple callback list. In fact.. I could leave that out of this library entirely as it may be out of the scope of my simple project. The medusa/asyncore project is 847 lines of c++ code including a test case and demo. I was hoping to stay around that number. Thanks, everyone for your input so far, I am rather new to ocaml and all the resources that have been pointed out to me have been enlightening on more subjects than this.