From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 543127F747 for ; Mon, 18 Aug 2014 18:29:31 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of thomas.braibant@gmail.com) identity=pra; client-ip=209.85.212.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="thomas.braibant@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of thomas.braibant@gmail.com designates 209.85.212.182 as permitted sender) identity=mailfrom; client-ip=209.85.212.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="thomas.braibant@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f182.google.com) identity=helo; client-ip=209.85.212.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="postmaster@mail-wi0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQBAJ8p8lPRVdS2m2dsb2JhbABZg2BXBIJ4tACWBIdWAYEYCBYQAQEBAQEGCwsJFCmEBAEBBBIRHQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEwgaiAsBAxENn3BriyuBcoMQigUKGScNZoRNEQEBBA6BHo4gB4J5gVMFkiCDK4Z3kxEYKYUQOy8FgkoBAQE X-IPAS-Result: AoQBAJ8p8lPRVdS2m2dsb2JhbABZg2BXBIJ4tACWBIdWAYEYCBYQAQEBAQEGCwsJFCmEBAEBBBIRHQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEwgaiAsBAxENn3BriyuBcoMQigUKGScNZoRNEQEBBA6BHo4gB4J5gVMFkiCDK4Z3kxEYKYUQOy8FgkoBAQE X-IronPort-AV: E=Sophos;i="5.01,887,1400018400"; d="scan'208";a="89732973" Received: from mail-wi0-f182.google.com ([209.85.212.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Aug 2014 18:29:26 +0200 Received: by mail-wi0-f182.google.com with SMTP id d1so3934290wiv.9 for ; Mon, 18 Aug 2014 09:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PPM86uNxt5B/jSRAHvE6t/mf5COEzxZiEWgBkg1xWDM=; b=aibMdLNglwXuKjPuJbRXnrlncEbXbQFCmFlsug5srJis5mXw/0bXAixgaax40KLPiC HODOBO0TqDNjARw7HTkts8+vnBviL95uZ5kokUtjSKKwjG2BuCtg+c2C8eM667FbqwOU cA7rfPs/dvHbIvWRw7W2zlvK4vn6hlzZ8n5iYBSzTVqxU9Ox/t793/tOWwAZXQu4e8gm bUaCVD8EBNf+yZcq+f0OeH5iQ+qyO4Zr6y3JFJTd1zbO4ukILbHviYOnPAmdoZqDEWCd xG9e2jLo/3pUu/gmvFJb63JT2IeZsckSw8qSF1NLDP+gTYJ3xgDDapHdLE/6NGAu++ME wiMA== X-Received: by 10.194.200.74 with SMTP id jq10mr9942416wjc.110.1408379365555; Mon, 18 Aug 2014 09:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.226 with HTTP; Mon, 18 Aug 2014 09:29:04 -0700 (PDT) In-Reply-To: <20140818161029.GA13445@notk.org> References: <20140818161029.GA13445@notk.org> From: Thomas Braibant Date: Mon, 18 Aug 2014 18:29:04 +0200 Message-ID: To: Adrien Nader Cc: OCaML Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Unix file descriptors vs. in/out channels 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 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