]> 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