From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id B13D0BC69 for ; Sat, 15 Sep 2007 11:15:03 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOo/60bAXQImlWdsb2JhbACOEgEBAQEHBAYPGA X-IronPort-AV: E=Sophos;i="4.20,258,1186351200"; d="scan'208";a="811142" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 15 Sep 2007 11:15:43 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8F9FKeb001138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sat, 15 Sep 2007 11:15:20 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAK4/60bAbSoIh2dsb2JhbACOEgEBAQgKJw X-IronPort-AV: E=Sophos;i="4.20,258,1186351200"; d="scan'208";a="1230049" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Sep 2007 11:15:43 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l8F9FfU6023793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 15 Sep 2007 11:15:42 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id l8F9FfRw023791 for caml-list@inria.fr; Sat, 15 Sep 2007 11:15:41 +0200 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-095-014.pools.arcor-ip.net (dslb-088-073-095-014.pools.arcor-ip.net [88.73.95.14]) by webmail.in-berlin.de (IMP) with HTTP for ; Sat, 15 Sep 2007 11:15:41 +0200 Message-ID: <1189847741.46eba2bd9d121@webmail.in-berlin.de> Date: Sat, 15 Sep 2007 11:15:41 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Closing all open file descriptors References: <006b01c7f699$275fd6d0$017ca8c0@countertenor> <200709141000.l8EA04x12648@virtutech.se> <1189806728.46eb0288d38b8@webmail.in-berlin.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at discorde with ID 46EBA2A8.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 descriptors:01 markus:01 bandel:01 mattias:01 readdir:01 ocaml:01 ocaml:01 descriptors:01 sockets:01 fifos:01 2007,:98 imho:01 imho:01 Zitat von Markus E L : > > Oliver Bandel wrote: > > > Zitat von Dave Benjamin : > > > >> On Fri, 14 Sep 2007, Mattias Engdegård wrote: > >> > >> >> Probably irrelevant here, but this approach wouldn't work under Windows > >> >> (Unix.file_descr is the Win32 file handle at that point which is often > >> >> larger than 1024). More relevantly, Unix can be reconfigured to allow > for > >> >> more than 1024 open files. > >> > > >> > I think platform-dependent code is required here. The common way of > >> > doing this under Linux (and Solaris, probably) is to readdir > >> > /proc/PID/fd/. Windows is of course very different. > >> > >> I like this approach. It doesn't eliminate the need to convert ints to > >> descrs, > > > > On Unix, file-descriptors are identified by integer-values. > > > > In OCaml, you have abstract types for file-descriptors. > > So, how to convert them? I think, officially there is no way. > > By writing a C-function which does the conversion. This, of course > could only exist under Linux. [...] I think this would need to hack in the internals of OCaml. And I don't see that it really would be necessary. But to have the number of max_open_files IMHO would be fine. I mentioned that it might be called Sys.max_open_descr or similarly. > > Generally a function enumerate_my_open_files would not be such a bad > idea. You can gather together the files (names or descriptors) you have opened, if you want. After the work is done, close the channels/files. If you think you need all this for your daemon, I ask: why do you think you need it? If you write it, you have full control over all files you open, or if you are using sockets, there also should be no problem. Why do you want to have numbers for your opened files? You can have a filename and get a file_descr or a channel. You can use a Map, if you need to enumerate them. But you also could use a Map that has filenames as keys and file_descr or channels as value of the map. So, if you want to close one certain channel, you have your association. You also could usa a PID of a child as key, or both: a PID and a filename, or connection-ID or something like that. Instead of looking for libraries for all kind of possible applications, IMHO it's better to build the needed things by your own, using the already available libraries like Map, Set and so on. Or if you need FIFOs for the connections, there also is a module for that (Queue-module). Rethink your design and you possibly will not have a necessity for the functions you asked for. If you would say a littlebid more about the tasks of your daemon, one could give a more detailed answer. Ciao, Oliver