On Fri, Oct 2, 2009 at 4:20 PM, Dan Kegel <[email protected]> wrote: > On Fri, Oct 2, 2009 at 4:02 PM, Jacob Mandelson <[email protected]> wrote: >> Which reads like "all or nothing" to me, though I could imagine a (perverse?) >> implementation with each writer having a send buffer lower layer pulling >> data from multiple writers' send buffers in an interleaved manner. (But >> maybe there's something else which restricts sockets to a single send >> buffer.) > > http://www.opengroup.org/onlinepubs/000095399/functions/write.html > says > "An attempt to write to a pipe or FIFO has several major characteristics: > Atomic/non-atomic: A write is atomic if the whole amount written in > one operation is not interleaved with data from any other process. > This is useful when there are multiple writers sending data to a > single reader. Applications need to know how large a write request can > be expected to be performed atomically. This maximum is called > {PIPE_BUF}. This volume of IEEE Std 1003.1-2001 does not say whether > write requests for more than {PIPE_BUF} bytes are atomic, but requires > that writes of {PIPE_BUF} or fewer bytes shall be atomic." > (I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.) > and > "If fildes refers to a socket, write() shall be equivalent to send() > with no flags set." > > So there is at least some cause to worry about data interleaving > between processes > without the fancy SOCK_SEQPACKET.
Sounds like it would be possible to fix, though, by sending multiple chunks of the form <id><length><done flag><data> each of which is smaller than PIPE_BUF. FreeBSD is adding SOCK_SEQPACKET, but it'd be nice to not require an OS upgrade to use Chrome. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
