caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Closing all open file descriptors
Date: Sat, 15 Sep 2007 11:15:41 +0200	[thread overview]
Message-ID: <1189847741.46eba2bd9d121@webmail.in-berlin.de> (raw)
In-Reply-To: <x2lkb86gm5.fsf@hod.lan.m-e-leypold.de>

Zitat von Markus E L <ls-ocaml-2006@m-e-leypold.de>:

>
> Oliver Bandel wrote:
>
> > Zitat von Dave Benjamin <dave@ramenlabs.com>:
> >
> >> 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


  reply	other threads:[~2007-09-15  9:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-13 22:56 Dave Benjamin
2007-09-14  1:04 ` [Caml-list] " Erik de Castro Lopo
2007-09-14  6:35   ` Dave Benjamin
2007-09-14  6:48     ` Erik de Castro Lopo
2007-09-14  7:32       ` Dave Benjamin
2007-09-14  6:33 ` David Allsopp
2007-09-14  6:41   ` Dave Benjamin
2007-09-14 10:54     ` Andre Nathan
2007-09-14 10:00   ` Mattias Engdegård
2007-09-14 20:31     ` Dave Benjamin
2007-09-14 21:52       ` Oliver Bandel
2007-09-14 22:12         ` Markus E L
2007-09-15  9:15           ` Oliver Bandel [this message]
2007-09-15  9:26             ` Erik de Castro Lopo
2007-09-15 10:43               ` Oliver Bandel
2007-09-15 11:36                 ` Mattias Engdegård
2007-09-15 11:57                   ` Oliver Bandel
2007-09-15 14:27                     ` Markus E L
2007-09-15 12:16                   ` Oliver Bandel
2007-09-15 14:29                     ` Markus E L
2007-09-15 18:04                       ` skaller
2007-09-15 14:17                   ` Markus E L
2007-09-15 14:16                 ` Markus E L
2007-09-15 15:58                   ` Eric Cooper
2007-09-15 16:17                     ` Markus E L
2007-09-15 18:33                       ` skaller
2007-09-15 17:44                   ` skaller
2007-09-14 10:10 ` Gerd Stolpmann
2007-09-14 11:56 ` Oliver Bandel
2007-09-17 11:00 ` Ville-Pertti Keinonen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1189847741.46eba2bd9d121@webmail.in-berlin.de \
    --to=oliver@first.in-berlin.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).