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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 7022A7ED27 for ; Wed, 6 Jun 2012 15:06:52 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAPRUz0/V+6tl/2dsb2JhbABFtDWBB4JZgTQoT4d0lgShJYs4gl+CNmADlRuJIoZXgmI X-IronPort-AV: E=Sophos;i="4.75,724,1330902000"; d="scan'208";a="161591038" Received: from eneide.happyleptic.org ([213.251.171.101]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 06 Jun 2012 15:06:52 +0200 Received: from extranet.securactive.org ([82.234.213.170] helo=ccellier.rd.securactive.lan) by eneide.happyleptic.org with esmtp (Exim 4.72) (envelope-from ) id 1ScGQh-0002Zs-JZ for caml-list@inria.fr; Wed, 06 Jun 2012 15:37:43 +0200 Received: from rixed by ccellier.rd.securactive.lan with local (Exim 4.77) (envelope-from ) id 1ScFwk-00062k-Fz for caml-list@inria.fr; Wed, 06 Jun 2012 15:06:46 +0200 Date: Wed, 6 Jun 2012 15:06:46 +0200 From: rixed@happyleptic.org To: caml-list@inria.fr Message-ID: <20120606130646.GA23115@securactive.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Caml-list] Unix.single_write, doc and atomicity I was reading the code for unix_single_write recently, and noticed two strange things that I prefer to discuss here before filling the bug tracker with dubious tickets. First, the doc of Unix.single_write claims that this function "attemps to write only once", although the underlying unix_single_write C function clearly loops around a write if the buffer being written is larger than the internal buffer (16K). So if one large buffer is written and an error happens after the first 16K then the written file is now corrupt. Looks like a bug. At the very least, the documentation should state that single_write can write atomicaly only buffer smaller than 16K. But I'd prefer a solution based on dynamic memory allocation for the required iobuf. Then, while we are on atomicity, another annoying thing: as the giant lock is released during the write some other thread may perform another single_write on the same file handler and again if the written buffers are larger than 16K the simultaneous write loop may interleave the written chunks. In other words, the nice atomicity properties of unix files opened with O_APPEND flag no longer holds. Although the doc does not pretend that the writes will be atomic in this situation, this is quite sad. So this boils down to : unix_single_write really should perform a single write! What do you think?