Re: [Caml-list] file descriptor leaks?

[Henri DF <henri.dubois-ferriere@epfl.ch>]

here's a relevant message explaining why ocaml gc doesn't collect file 
descriptiors:

http://caml.inria.fr/archives/200311/msg00264.html


By the way , from R. Jones tutorial (chap 9), i saw:

<quote>Calls to read_file open the file but don't close it. Because OCaml 
uses a 
full garbage collector chan isn't collected until some (unknown, 
asynchronous) time later when the minor heap becomes full. This means that 
open file descriptors build up waiting to be collected in one go. If files 
is a long list, then this code is likely to fail when the OS limit on the 
number of open files is reached.
</quote>

which i guess is inaccurrate?


henri

On Tue, 4 May 2004, Basile Starynkevitch local wrote:

> On Mon, May 03, 2004 at 04:32:32PM -0700, Ker Lutyn wrote:
> [...]
> 
> > Assuming f does not close the fd when it's done, [...] is this
> > better?
> > 
> > while true do
> >   let fd, _ = Unix.accept sock in
> >   let g fd = try f fd; Unix.close fd with e -> Unix.close fd; raise e in
> >   ignore (Thread.create g fd)
> > done
> > 
> 
> Yes. First, a file descriptor is mostly heavy in the OS kernel side;
> inside a process, an fd is just an integer. To free the fd (kernel)
> resource, you *have* to call Unix.close (i.e. to call the close(2)
> system call).
> 
> Second, there are no implicit call to the close(2) system call inside
> the Ocaml system (there used to be, long time ago, implicit close of
> channels by the GC. This finalization is gone).
> 
> So yes, every file descriptor you got thru accept has to be explicitly
> closed. Some higher level functions in the Unix library happen to do
> so.
> 
> 



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