From: Thomas Braibant <thomas.braibant@gmail.com>
To: Adrien Nader <adrien@notk.org>
Cc: OCaML Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Unix file descriptors vs. in/out channels
Date: Mon, 18 Aug 2014 18:29:04 +0200 [thread overview]
Message-ID: <CAHR=VkzpP+t+duohpf5uxwKJiaL5MZJDXXyWpf8YFgFYgOpfew@mail.gmail.com> (raw)
In-Reply-To: <20140818161029.GA13445@notk.org>
Hi Adrien,
Thanks a lot for clarifying that one should not use accesses through
the file descriptors and the in/out_channels.
I am pretty sure that using in/out_channel_of_descr more than once
will be an issue too, looking at the code in io.c [1] (at least
because the close function would be called twice on the same fd, which
might refer to something else at that point in time, as Goswin pointed
out recently).
The only part that I still do not fully understand is why the
following code, that does not mix accesses through the file_descr and
the channels has a behavior that depends on the fact that I compute
the length of the input channel. I would expect the out_channel to be
flushed by the call to printf with "%!", isn't it?
let test =
let open Unix in
let fd = openfile "foo.bar" [O_RDWR; O_TRUNC; O_CREAT] 0o640 in
Printf.printf "openfile\n%!";
let o = out_channel_of_descr fd in
Printf.printf "out_channel_of_descr\n%!";
let i = in_channel_of_descr fd in
Printf.printf "in_channel_of_descr\n%!";
debug "1" i o;
let _ = Printf.fprintf o "test1\n%!" in
debug "2" i o;
let _ = input_char i in
close_in i;
Printf.printf "Ok\n%!"
[1] https://github.com/ocaml/ocaml/blob/774e30e138dc22a5acd6cfac03ae25194ae8cd6e/byterun/io.c
On Mon, Aug 18, 2014 at 6:10 PM, Adrien Nader <adrien@notk.org> wrote:
> Hi,
>
> You cannot safely mix buffered (in/out_channel) and un-buffered
> (file_descr) uses of the same underlying resource.
>
> IIRC an in_channel or out_channel has a buffer in OCaml memory.
> If you close the underlying file_descr of an out_channel with
> functions operating on file desriptors directly, it is possible that
> some data will still be buffered.
> If you read alternatively through file_descr and in_channel, you might
> skip some data if reading with the in_channel reads more than just "n
> chars" (it could read 4K for instance, I'm not completely sure).
>
> As for using in/out_channel_of_descr more than once, I don't know
> offhand: if it creates new buffers each time (likely), it will be an
> issue.
>
> --
> Adrien Nader
next prev parent reply other threads:[~2014-08-18 16:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 14:42 Thomas Braibant
2014-08-18 16:10 ` Adrien Nader
2014-08-18 16:15 ` Edouard Evangelisti
2014-08-18 16:29 ` Thomas Braibant [this message]
2014-08-18 16:33 ` Xavier Leroy
2014-08-18 16:52 ` Thomas Braibant
2014-08-18 16:57 ` Xavier Leroy
2014-08-18 17:18 ` Thomas Braibant
2014-08-18 17:55 ` David Sheets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHR=VkzpP+t+duohpf5uxwKJiaL5MZJDXXyWpf8YFgFYgOpfew@mail.gmail.com' \
--to=thomas.braibant@gmail.com \
--cc=adrien@notk.org \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox