* [Caml-list] Unix.single_write, doc and atomicity @ 2012-06-06 13:06 rixed 2012-06-06 13:17 ` Török Edwin 2012-06-16 23:11 ` Goswin von Brederlow 0 siblings, 2 replies; 5+ messages in thread From: rixed @ 2012-06-06 13:06 UTC (permalink / raw) To: caml-list 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] Unix.single_write, doc and atomicity 2012-06-06 13:06 [Caml-list] Unix.single_write, doc and atomicity rixed @ 2012-06-06 13:17 ` Török Edwin 2012-06-06 13:29 ` oliver 2012-06-06 13:34 ` rixed 2012-06-16 23:11 ` Goswin von Brederlow 1 sibling, 2 replies; 5+ messages in thread From: Török Edwin @ 2012-06-06 13:17 UTC (permalink / raw) To: rixed; +Cc: caml-list On 06/06/2012 04:06 PM, rixed@happyleptic.org wrote: > 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). Are we looking at the same file / function? The one that loops is unix_write, I don't see any loops in unix_single_write: CAMLprim value unix_single_write(value fd, value buf, value vofs, value vlen) { long ofs, len; int numbytes, ret; char iobuf[UNIX_BUFFER_SIZE]; Begin_root (buf); ofs = Long_val(vofs); len = Long_val(vlen); ret = 0; if (len > 0) { numbytes = len > UNIX_BUFFER_SIZE ? UNIX_BUFFER_SIZE : len; memmove (iobuf, &Byte(buf, ofs), numbytes); enter_blocking_section(); ret = write(Int_val(fd), iobuf, numbytes); leave_blocking_section(); if (ret == -1) uerror("single_write", Nothing); } End_roots(); return Val_int(ret); > > So this boils down to : unix_single_write really should perform a single write! AFAICT it does only a single write. Best regards, --Edwin ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] Unix.single_write, doc and atomicity 2012-06-06 13:17 ` Török Edwin @ 2012-06-06 13:29 ` oliver 2012-06-06 13:34 ` rixed 1 sibling, 0 replies; 5+ messages in thread From: oliver @ 2012-06-06 13:29 UTC (permalink / raw) To: Török Edwin; +Cc: rixed, caml-list Hello, single_write-docs say: "Same as write, but attempts to write only once. Thus, if an error occurs, single_write guarantees that no data has been written." Attempts does not mean guarantee. If it fails, it will give an error. But I wonder if "Thus, if an error occurs, single_write guarantees that no data has been written." is correct for all devices and situations. It may also be possible to write less bytes than one wants. In this case "guarantees that no data has been written" seems to be violated. For these cases, the docs need to be corrected. More precise IMHO would be: "If no error occured, all data has been written sucessfully in one attempt." Ciao, Oliver On Wed, Jun 06, 2012 at 04:17:02PM +0300, Török Edwin wrote: > On 06/06/2012 04:06 PM, rixed@happyleptic.org wrote: > > 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). > > Are we looking at the same file / function? > The one that loops is unix_write, I don't see any loops in unix_single_write: > > CAMLprim value unix_single_write(value fd, value buf, value vofs, value vlen) > { > long ofs, len; > int numbytes, ret; > char iobuf[UNIX_BUFFER_SIZE]; > > Begin_root (buf); > ofs = Long_val(vofs); > len = Long_val(vlen); > ret = 0; > if (len > 0) { > numbytes = len > UNIX_BUFFER_SIZE ? UNIX_BUFFER_SIZE : len; > memmove (iobuf, &Byte(buf, ofs), numbytes); > enter_blocking_section(); > ret = write(Int_val(fd), iobuf, numbytes); > leave_blocking_section(); > if (ret == -1) uerror("single_write", Nothing); > } > End_roots(); > return Val_int(ret); > > > > > > So this boils down to : unix_single_write really should perform a single write! > > AFAICT it does only a single write. > > Best regards, > --Edwin > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] Unix.single_write, doc and atomicity 2012-06-06 13:17 ` Török Edwin 2012-06-06 13:29 ` oliver @ 2012-06-06 13:34 ` rixed 1 sibling, 0 replies; 5+ messages in thread From: rixed @ 2012-06-06 13:34 UTC (permalink / raw) To: caml-list -[ Wed, Jun 06, 2012 at 04:17:02PM +0300, Török Edwin ]---- > Are we looking at the same file / function? > The one that loops is unix_write, I don't see any loops in unix_single_write: Of course I was not reading the good one. Too many open terminals I guess. Sorry for the noise. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] Unix.single_write, doc and atomicity 2012-06-06 13:06 [Caml-list] Unix.single_write, doc and atomicity rixed 2012-06-06 13:17 ` Török Edwin @ 2012-06-16 23:11 ` Goswin von Brederlow 1 sibling, 0 replies; 5+ messages in thread From: Goswin von Brederlow @ 2012-06-16 23:11 UTC (permalink / raw) To: rixed; +Cc: caml-list rixed@happyleptic.org writes: > 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? As others have said you were reading the wrong function. But you do have a point with the copying of data in 16K chunkd and writing them out in bits and pices. This destroys the atomicity of write (as far as it is given at all, pipes garanty only 4k atomic writes under linux). Also the copying is a waste of cpu power. There is a nice solution to this: Bigarray. The data part of a Bigarray is allocated from outside the ocaml heap and is unmovable. That means that C code can look up the address and size of the data, release the runtime system and write the data in the background without having to copy it first. The extunix module (http://extunix.forge.ocamlcore.org/) has bindings for read, write, pread and pwrite functions with Bigarrays that retain all the atomicity the systemcalls provide. Extunix also provides read, write, pread and pwrite functions for strings with better defined behaviour on error: ---------------------------------------------------------------------- (** [all_write fd buf ofs len] writes up to [len] bytes from file descriptor [fd] into the string [buf] at offset [ofs]. [all_write] repeats the write operation until all characters have been written or an error occurs. Returns less than the number of characters requested on EAGAIN, EWOULDBLOCK but never 0. Continues the write operation on EINTR. Raises an Unix.Unix_error exception in all other cases. *) external unsafe_all_write: Unix.file_descr -> string -> int -> int -> int = "caml_extunix_all_write" let all_write fd buf ofs len = if ofs < 0 || len < 0 || ofs > String.length buf - len then invalid_arg "ExtUnix.all_write" else unsafe_all_write fd buf ofs len (** [single_write fd buf ofs len] writes up to [len] bytes from file descriptor [fd] into the string [buf] at offset [ofs]. [single_write] attempts to write only once. Returns the number of characters written or raises an Unix.Unix_error exception. *) external unsafe_single_write: Unix.file_descr -> string -> int -> int -> int = "caml_extunix_single_write" let single_write fd buf ofs len = if ofs < 0 || len < 0 || ofs > String.length buf - len then invalid_arg "ExtUnix.single_write" else unsafe_single_write fd buf ofs len (** [write fd buf ofs len] writes up to [len] bytes from file descriptor [fd] into the string [buf] at offset [ofs]. [write] repeats the write operation until all characters have been written or an error occurs. Raises an Unix.Unix_error exception if 0 characters could be written before an error occurs. Continues the write operation on EINTR. Returns the number of characters written in all other cases. *) external unsafe_write: Unix.file_descr -> string -> int -> int -> int = "caml_extunix_write" let write fd buf ofs len = if ofs < 0 || len < 0 || ofs > String.length buf - len then invalid_arg "ExtUnix.pwrite" else unsafe_write fd buf ofs len (** [intr_write fd buf ofs len] writes up to [len] bytes from file descriptor [fd] into the string [buf] at offset [ofs]. [intr_write] repeats the write operation until all characters have been written or an error occurs. Raises an Unix.Unix_error exception if 0 characters could be written before an error occurs. Does NOT continue on EINTR. Returns the number of characters written in all other cases. *) external unsafe_intr_write: Unix.file_descr -> string -> int -> int -> int = "caml_extunix_intr_write" let intr_write fd buf ofs len = if ofs < 0 || len < 0 || ofs > String.length buf - len then invalid_arg "ExtUnix.intr_write" else unsafe_intr_write fd buf ofs len ---------------------------------------------------------------------- MfG Goswin ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-06-16 23:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-06 13:06 [Caml-list] Unix.single_write, doc and atomicity rixed 2012-06-06 13:17 ` Török Edwin 2012-06-06 13:29 ` oliver 2012-06-06 13:34 ` rixed 2012-06-16 23:11 ` Goswin von Brederlow
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox