On Friday, November 14, 2003, at 03:57 PM, Christophe Raffalli wrote:

> Why ? Could you elaborate ?

This is what I had in mind:

If your file descriptor f is bound to a pipe, then close() will
send a SIGPIPE or and end-of-file to the process at the other end
of the pipe.  This is a visible side-effect.

If f is bound to a socket, then close() will not only send
and end-of-file to the other end, but it will also release
the port number, changing the outcome of a further bind() call.
Another side-effect.

If you call exec(), then the new program will inherit all
open file descriptors.  More visible side-effects.

More examples (that I hadn't thought of) were given by other
people on this list.

For these reasons, close() must be provided to the programmer for
explicit calling, because its semantics goes beyond simple
deallocation of resource.

Since close() is provided, if you want the GC to close your
descriptors, you can attach finalisation functions to them.
In that case, don't forget to call Gc.full_major() before exec().

In my opinion, doing it automatically would only encourage sloppy
programming by hiding errors in a non-deterministic way.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners