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 6FD9BBB83 for ; Fri, 18 Aug 2006 23:33: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 k7ILXPJn007787 for ; Fri, 18 Aug 2006 23:33:25 +0200 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 XAA13260 for ; Fri, 18 Aug 2006 23:33:24 +0200 (MET DST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7ILXNZV017683 for ; Fri, 18 Aug 2006 23:33:24 +0200 Received: by nf-out-0910.google.com with SMTP id y38so1709868nfb for ; Fri, 18 Aug 2006 14:33:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YXEwdMk9LYMZX0vu+5T0cfVY8eCqJiX9EQ6KzJy8OCyT01FxWH909UYA/AohoHvIKjmV2UOWbfBdmfrPoarZM1tf3Zm1ZsEbJg+jxLiOLIvyZTe+jdIWKzFbDi/sAfP2s2T1zEM0zpTQMHGz36VDtNmUffk5ZawIJaqSjbTEMng= Received: by 10.48.220.15 with SMTP id s15mr4585968nfg; Fri, 18 Aug 2006 14:33:23 -0700 (PDT) Received: by 10.78.158.8 with HTTP; Fri, 18 Aug 2006 14:33:23 -0700 (PDT) Message-ID: Date: Fri, 18 Aug 2006 14:33:23 -0700 From: "Nathaniel Gray" To: "Bardur Arantsson" Subject: Re: [Caml-list] Re: Help interfacing with C Cc: caml-list@inria.fr In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-j-chkmail-Score: MSGID : 44E63224.000 on concorde : j-chkmail score : X : 0/20 1 X-Miltered: at concorde with ID 44E63224.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; interfacing:01 pairs:01 descriptors:01 ocaml:01 unix:01 descriptors:01 ocaml:01 buffer:01 pairs:01 iter:01 unix:01 allocating:01 iterating:01 sdu:01 wrote: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=RCVD_BY_IP autolearn=disabled version=3.0.3 On 8/16/06, Bardur Arantsson wrote: > Nathaniel Gray wrote: > > Hi folks, > [--snip--] > > have select work on (file_descr * 'a) pairs instead of plain file > > descriptors. > > It's much easier than that; just define a conversion in OCaml: > > external file_descr_to_int : file_descr -> int = "%identity"; > external int_to_file_descr : int -> file_descr = "%identity"; > > and use > > let my_select r w e t = > let r' = List.map file_descr_to_int r > and w' = List.map file_descr_to_int w > and e' = List.map file_descr_to_int e > in > Unix.select r' w' e' t;; > > You seem to be doing the mapping of the result values, but that is just > a question of mapping int_to_file_descr over the result lists. Thanks, but this doesn't really help. Perhaps I should say what I'm trying to accomplish instead of trying to let the types speak for me. The point is that when you select on a list of file descriptors there's a very good chance that you don't *only* care that file descriptor f is ready, you also have some ocaml data structure associated with f that you want to use with it in some way. For example, you probably have a string to write or a buffer to read into. The current API is sort of a minimal translation of the select system call to OCaml, which is a good starting point, but not great IMHO. In order to match up each file descriptor to its data you have to scan the output fd list yet again, after it's already been done once at the C level, and since you don't know how/if it's sorted you end up with unsatisfying time complexity for the whole thing. It's not critical, since the lists are small, but it hardly brings a smile to your face. On the other hand, imagine a select2 that takes lists of (fd, 'a) pairs and returns the same. The results become incredibly easy to handle, with no scanning necessary. You probably just List.iter a simple read/write function over the result and you're done. > > Of course this may be rather slower than your version, but Unix.select > is very very slow anyway since it's allocating at least one list for > every single call... and iterating through all(?) the file descriptors > in the input FD_SETs as well. > > [Shameless plug below: If you want better performance, you might want > to try > > > http://www.imada.sdu.dk/~bardur/personal/45-programs/ocaml-events/ocaml-events-0.1.0.tar.bz2 > > I must warn you, though, that there are no timers or signal handling: It > turned out I didn't them for my particular application, so I haven't > bothered adding support. The actual FD polling/selection has worked very > reliably for me.] -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->