[Caml-list] file descriptor leaks?

[Ker Lutyn]

Suppose the central loop of my server looks like this:

while true do
let fd, _ = Unix.accept sock in
ignore (Thread.create f fd)
done

Assuming f does not close the fd when it's done, is this a fd leak? And 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

Thanks -

__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover

-------------------
To unsubscribe, mail caml-lis...@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

[Basile Starynkevitch local]

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.

--
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - phone +33 1 3963 5197 - mobile 6 8501 2359
http://cristal.inria.fr/~starynke --- all opinions are only mine

[Henri DF]

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

-------------------

[Richard Jones]

On Tue, May 04, 2004 at 11:15:44AM +0200, Henri DF wrote:
> <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>

Yes, I think this part of the tutorial is wrong.

Rich.

--
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
If I have not seen as far as others, it is because I have been
standing in the footprints of giants. -- from Usenet