Re: [Caml-list] Closing all open file descriptors

[Markus E L <ls-ocaml-2006@m-e-leypold.de>]

Oliver Bandel wrote:

> Zitat von Mattias Engdegå   rd <mattias@virtutech.se>:
>
>> >If you have all your open descriptors in a list,
>> >you can close them after a fork.
>>
>> That approach does not compose well --- descriptors opened by
>> a library will be excluded. The only good way is to ask the system.
>>
>
>
> What do you mean with "does not compose well"?
> Do you see OCaml-specific problems here, or what?

No.

> In C, there is a function fileno(3).
> Possibly this is, what people discussing
> in this thread are looking for.

No. You're barking up the completely wrong tree. We are looking for a
way to iterate over ALL open filedescriptors, wether inherited from
the parent process (which we don't control / haven't written
ourselves, so no recurrence to set_closeon_exec), or opened by a
library procedure or opened by our own program.

> This would be a thing that could be included in
> Ocaml, but the result would not be an integer-value,

Bah. Nobody asked for integer values.

> because OCaml uses abstract types for file descriptors.

Yes, yes, we know.

> I'm a littlebid sceptical on using high-level and low-level
> stuff together. In C it's also not recommended to mix buffered
> and non-buffered IO, 

But you _have_ to do it, how else could you do buffered IO on sockets?

> and so in OCaml, which is quite more
> high-level stuff, I would be even more sceptical on mixing
> these things together.

No, it's very similar to the relationship between stdio and unix file
descriptors.

> As a general rule I would recommend, not to mix the different
> IO-possibilities.

It's not so rare that you would have to do a select() on some I/O
channel you'd on the other side rather prefer to do buffered I/O with
instead of writing (again) your own buffering. Fortunately this
works. 

So I rate "I would not recommend" rather too strong. It works and it
is AFAI understand guaranteed to work. One just has to be prepared to
understand the interaction between buffered and unbuffered I/O, which
are a _little_ bit more complex than one type of I/O alone, but --
nonetheless -- managable.

Regards -- Markus