From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6A6D47EE51 for ; Sat, 11 May 2013 12:14:15 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.17.11; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.17.11; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.17.11; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMCAIkZjlHU4xELm2dsb2JhbABZvjeCOYJwfRYOAQEBAQEGCwsJFCiCHwEBBScTTwsYCSUPBSiILQEWs0kfiGCPL4NVA5crhgSOQw X-IPAS-Result: AjMCAIkZjlHU4xELm2dsb2JhbABZvjeCOYJwfRYOAQEBAQEGCwsJFCiCHwEBBScTTwsYCSUPBSiILQEWs0kfiGCPL4NVA5crhgSOQw X-IronPort-AV: E=Sophos;i="4.87,652,1363129200"; d="scan'208";a="16861814" Received: from mout.web.de ([212.227.17.11]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 May 2013 12:14:15 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0Lp760-1U5KpV3O5M-00fE1H for ; Sat, 11 May 2013 12:14:13 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1Ub6of-0001PF-3F for caml-list@inria.fr; Sat, 11 May 2013 12:14:13 +0200 Date: Sat, 11 May 2013 12:14:13 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20130511101412.GH3334@frosties> References: <20130510231041.GA29570@frosties> <1368265499.5134.0@samsung> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1368265499.5134.0@samsung> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:fd1DRMEPGTscSZ00nSvYRctPKLbp77BwK37HH6GTACF EbBpbjUE0YKoWEyBy3efzzV526WAM8STri1A2rK+2uhDej088n /8n+jjz9Vi4kLiWBtBBkcJ1kb3Wv+9Dr/jRdxYjMy1Fat70fL6 uX9tfnU2sTteiQqkgohiramvkc0kjkbxXRoyqimUujbQHTA8Vd sFDzUzMKDSECdC6/8mD5g== Subject: Re: [Caml-list] Linux epoll bindings On Sat, May 11, 2013 at 11:44:59AM +0200, Gerd Stolpmann wrote: > Am 11.05.2013 01:10:41 schrieb(en) Goswin von Brederlow: > >I think the best feature of Linux epoll is that the struct epoll_event > >contains a epoll_data_t where one can store a pointer, int, uint32_t > >or uint64_t. Core.Std.Linux_ext.Epoll (and the other epoll bindings) > >seem to always store the Unix.file_descr there. > > > >In my case, and probably most cases, I have different FDs in the mix > >that need to do different things when their event is triggered. For > >example the server socket needs to call accpet() on POLLIN while > >client sockets need to (continue to) parse requests. So every FD has a > >bit of state associated with it that tells what to do with it. And I > >need a Hashtbl.t to lookup the state for each FD that gets an event. > > Using a hashtbl or other external container is the right thing to > do. You cannot put an OCaml pointer into a kernel structure, because > the OCaml memory manager might want to move the OCaml block around, > and there is no way to update the pointer when OCaml wants to do > this. So you cannot get around this indirection here (which is also > very cheap at runtime, so I also wonder where the runtime > improvement would be). > > Gerd It is true that one needs an indirection to keep the GC happy. But that would be something for the Epoll module to handle. Not for me. Wether it does that in the ocaml code or in the C stubs is open to implementation. The improvement would be not to have to manage the hashtbl manually at every place where the epoll set is modified. > >Now wouldn't it be much better to store a 'a in the epoll_data_t > >instead of the FD? That would allow storing a Unix.file_descr just > >like now, a closure or any other data structure one wishes to > >associate with the event being waited for. Something like (loosely > >based on janestreets core): > > > >module Epoll: sig > > type op = ADD | MOD | DEL > > > > type flags (* EPOLLIN | EPOLLOUT | .... *) > > > > type 'a event = { > > flags : flags; > > data : 'a > > } > > > > type 'a t > > > > val create : 'a. (int -> 'a t) > > (** create max_events creates an epoll object able to process up > > to max_events per wait call. *) > > > > val ctl : 'a t -> op -> Unix.file_descr -> 'a event -> unit > > (** ctl t op fd event adds, modifies, deletes the association > >between > > the fd and the event. *) > > > > val wait : 'a t -> [ `After of float | `Immediately | `Never ] > > -> [ `Ok | `Timeout ] > > (** wait t timeout blocks until at least one file descriptor in t > > is ready for one of the events it is being watched for, or > >timeout > > passes. *) > > > > val iter : 'a t -> (flags -> 'a -> unit) -> unit > > val fold : 'a t -> 'b -> ('b -> flags -> 'a -> 'b) -> 'b > > (** iterate or fold over pending events *) > >end > > > > > >Anyone know of epoll bindings like that? I only found the FD kind with > >google. > > > >MfG > > Goswin MfG Goswin