Browse thread
[Caml-list] file descriptor leaks?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-05-04 (09:15) |
From: | Henri DF <henri.dubois-ferriere@e...> |
Subject: | Re: [Caml-list] file descriptor leaks? |
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