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 47B247F747 for ; Mon, 18 Aug 2014 18:53:07 +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=74.125.82.43; 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 74.125.82.43 as permitted sender) identity=mailfrom; client-ip=74.125.82.43; 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-wg0-f43.google.com) identity=helo; client-ip=74.125.82.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="thomas.braibant@gmail.com"; x-sender="postmaster@mail-wg0-f43.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQCAE4u8lNKfVIrlWdsb2JhbABZhDcEgni0Ap1aAYEYCBYQAQEBAQcNCQkSK4QEAQEDARIRHQEbHQEDAQsGBQsPAiYCAiIBEQEFARwGNYgLAQMJCJ9+a4srgXKDEIoPChknDWaETREBBQ6BHohThU0HgnmBUwEEjxKDDooikxEYKYUQOy+CTwEBAQ X-IPAS-Result: AhQCAE4u8lNKfVIrlWdsb2JhbABZhDcEgni0Ap1aAYEYCBYQAQEBAQcNCQkSK4QEAQEDARIRHQEbHQEDAQsGBQsPAiYCAiIBEQEFARwGNYgLAQMJCJ9+a4srgXKDEIoPChknDWaETREBBQ6BHohThU0HgnmBUwEEjxKDDooikxEYKYUQOy+CTwEBAQ X-IronPort-AV: E=Sophos;i="5.01,887,1400018400"; d="scan'208";a="89735063" Received: from mail-wg0-f43.google.com ([74.125.82.43]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 18 Aug 2014 18:53:06 +0200 Received: by mail-wg0-f43.google.com with SMTP id l18so5201075wgh.26 for ; Mon, 18 Aug 2014 09:53:06 -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=AaMx0uTb65FEDaXW1WLrl8NNPch0Ai9F4Aqg7ruimHM=; b=wtzOxsbkupApNDZ/N4UwFnxQKANw5fsBayvtS3SdlI9ZZLDAtnGQuHGhbvMvbd8nL8 mQIDvTuxOwzbyAyhyOrzQ/6m+OQeonmR6v8hLVMTRnCPiFeCgApVKHQOuSlAICg28Mav lPlLu/UwjMiB7foSwmOgtIfo3r/56TKt5n6u8MDxpY0ZvbvAd/mV0BdGPOfXCdyCvIF4 LAqzRF0gHRIVRq6kyxxqMLZqsDVJKHjAL57j1jRx6wB++KNedFz1XwZR/nlrAbgq3wss WMtC899z1doF7HFwYqQD91w7A2DW9wEFXnAZKqmXBNrr/fH1ERLiuOgOtx1he++BVEFo XPCA== X-Received: by 10.194.22.166 with SMTP id e6mr44271063wjf.88.1408380786451; Mon, 18 Aug 2014 09:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.226 with HTTP; Mon, 18 Aug 2014 09:52:46 -0700 (PDT) In-Reply-To: <53F22AEB.5070506@inria.fr> References: <53F22AEB.5070506@inria.fr> From: Thomas Braibant Date: Mon, 18 Aug 2014 18:52:46 +0200 Message-ID: To: Xavier Leroy Cc: OCaML Mailing List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Unix file descriptors vs. in/out channels 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