Re: [Caml-list] Unix file descriptors vs. in/out channels

[Thomas Braibant <thomas.braibant@gmail.com>]

Hi Xavier.

Thanks for your answer.

>> Therefore, I assume that I cannot use
>> Unix.in_channel_of_descr and Unix.out_channel_of_descr more that once
>> for my file-descriptor (because otherwise, these channels would not be
>> reclaimed).
>
> I don't quite understand your remark.  You need to close (explicitly
> and at once) all in_channels and out_channels associated with your
> file_descr, once you're done with it.  The first close_in/close_out
> will close the underlying FD, and the others will ignore the fact that
> the FD is already closed.

Well, I was thinking about the following situation

  let open Unix in
  let fd = openfile "foo.bar" [O_RDWR; O_TRUNC; O_CREAT] 0o640 in
  let o = out_channel_of_descr fd in
  let i = in_channel_of_descr fd in
  let i2 = in_channel_of_descr fd in
  Printf.printf "1\n%!";
  close_in i;
  Printf.printf "2\n%!";
  close_in i2;
  Printf.printf "3\n%!";
  close_out o;
  Printf.printf "Ok\n%!"

that raises the fatal error: exception Sys_error("Bad file
descriptor"), and now, I do not understand your remark either :(.

> For a file opened in RW mode, the problem is that reads through
> the in_channel may not see the data written through the out_channel,
> even if you religiously flush the out_channel before reading anything.
> The reason is that in_channels are also buffered, and may hold stale
> data corresponding to the state of the file before recent writes.  And
> there is no flush operation for in_channels...
>
> This is another gotcha :-)  in_channels and out_channels maintain
> (their idea of) the current position in the file.  This helps avoiding
> unnecessary "lseek" operations to determine current position and
> length.  However, if you share a FD between two channels, the
> channels's idea of the current position is inconsistent with the
> actual position of the FD.

Good to know (especially the part about the in channels not being flushed).

> Bottom line: for your intended application, it's better to use Unix
> functions exclusively.  The trick with an (in_channel, out_channel) pair
> does work pretty well for sockets, named pipes and terminals, though.

That seems like a very good advice, and I will do likewise. (Even if
one minor issue is that it makes interacting with some third-party
libraries that use in/out channels as abstraction more complex.)

Best,
Thomas