Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Looking for stubs for sendmsg/recvmsg
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-11-21 (18:39)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: FDs as cutsom blocks instead of int
Sylvain Le Gall <> writes:

> On 20-11-2010, Goswin von Brederlow <> wrote:
>> Sylvain Le Gall <> writes:
>>> On 19-11-2010, Goswin von Brederlow <> wrote:
>>>> Sylvain Le Gall <> writes:
>>>>> On 19-11-2010, Goswin von Brederlow <> wrote:
>>>>>> Sylvain Le Gall <> writes:
>>>>>>> On 18-11-2010, Goswin von Brederlow <> wrote:
>>> The best example about this: you cannot delete a file that has an FD
>>> still open on it. This makes harder to remove temporary file (and this
>>> piece of code was precisely made to track FD on temporary files, that
>>> let 1000s of unremoved temp file). 
>>> Regards,
>>> Sylvain Le Gall
>> Which again speaks for my solution. The leaked FD will be closed much
>> faster (before the program terminates) and one can remove the tempfiles
>> while the program is still running.
> I think, this totally off-topic. But anyway, when a program create a
> temporary files it needs to remove ASAP, itself. I wouldn't 
> deliver a program with a notice like "sometimes FD leaked, not a
> problem, just remove $TMP/myprogram-*". 
> For the little story, the leaked FD (hence the temporary files) was
> 400MB each and it quickly get noticed after a few run (and a full HD).
> Regards,
> Sylvain Le Gall

Consider the following code:

(* Make sure everything is finalised at exit *)
let () = at_exit Gc.full_major

let remove_tempfile name _ =
  Unix.unlink name

let fd = Unix.openfile name ...
  Gc.finalise (remove_tempfile name) fd
  (* do whatever with the FD *)

This ensures the tempfile is closed and removed once it becomes
unreachable. One doesn't need to catch all exceptions to ensure the file
is removed even on errors. Or need reference counting if the FD is
referenced multiple times.

Currently the above fails because Unix.file_descr (int) isn't heap

I'm not saying it is a solves-all-problems solution. I just found it
verry helpfull with other abstract types that needed to be explicitly
closed before they can be discarded.