From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <adrien@notk.org>
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 D93327F747
	for <caml-list@sympa.inria.fr>; Mon, 18 Aug 2014 18:10:30 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  adrien@notk.org) identity=pra; client-ip=91.121.71.147;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="adrien@notk.org"; x-sender="adrien@notk.org";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of
  adrien@notk.org designates 91.121.71.147 as permitted sender)
  identity=mailfrom; client-ip=91.121.71.147;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="adrien@notk.org"; x-sender="adrien@notk.org";
  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@nautica.notk.org) identity=helo;
  client-ip=91.121.71.147;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="adrien@notk.org";
  x-sender="postmaster@nautica.notk.org";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAOok8lNbeUeT/2dsb2JhbABZgw2DVlDRVgGBIBZ3hAQBBSNWEAsaAgUTDgICDwUYMYhZrAaVDBeBLI4gB4J5NoEdBZxBAZUDg187gn4BAQE
X-IPAS-Result: AjMFAOok8lNbeUeT/2dsb2JhbABZgw2DVlDRVgGBIBZ3hAQBBSNWEAsaAgUTDgICDwUYMYhZrAaVDBeBLI4gB4J5NoEdBZxBAZUDg187gn4BAQE
X-IronPort-AV: E=Sophos;i="5.01,886,1400018400"; 
   d="scan'208";a="89730916"
Received: from nautica.notk.org ([91.121.71.147])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 18 Aug 2014 18:10:30 +0200
Received: by nautica.notk.org (Postfix, from userid 1003)
	id 5C201C009; Mon, 18 Aug 2014 18:10:29 +0200 (CEST)
Date: Mon, 18 Aug 2014 18:10:29 +0200
From: Adrien Nader <adrien@notk.org>
To: Thomas Braibant <thomas.braibant@gmail.com>
Cc: OCaML Mailing List <caml-list@inria.fr>
Message-ID: <20140818161029.GA13445@notk.org>
References: <CAHR=VkwXynFAJm13MwKrsJNgx4HeW_LU03BQxqD4S7prG1A8Rw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHR=VkwXynFAJm13MwKrsJNgx4HeW_LU03BQxqD4S7prG1A8Rw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Caml-list] Unix file descriptors vs. in/out channels

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