Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jun 2003 12:57:05 -0400 (EDT)
From:      "Matthew Hagerty" <matthew@mundomateo.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Are write() calls guaranteed atomic?
Message-ID:  <1720.216.120.158.65.1054573025.squirrel@www.mundomateo.com>
In-Reply-To: <20030602154917.GA97655@dan.emsphone.com>
References:  <1553.216.120.158.65.1054566440.squirrel@www.mundomateo.com>  <20030602154917.GA97655@dan.emsphone.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> In the last episode (Jun 02), Matthew Hagerty said:
>> I'm writing a server that receives data via a named pipe (FIFO) and
>> will always have more than one other process sending data to it, and
>> I'm concerned with preventing data multiplexing.  The data coming in
>> will be lines of text delimited with a newline, but the processes
>> writing the data have no knowledge of the FIFO, they simply think
>> they are writing to a file.  This being the case, the processes
>> writing the data give no regard to PIPE_BUF and may send data in
>> longer lengths (but probably never longer than 2K to 4K.)
>>
>> Will the kernel ensure that the data write() will be delivered to the
>> FIFO atomically even if the data is larger than PIPE_BUF, such that
>> two or more successive read() calls will retrieve the data in order?
>
> Pipes are always FIFO; it's part of their definition.  From SUSv3:
>
>   A read on the file descriptor fildes[0] shall access data written to
>   the file descriptor fildes[1] on a first-in-first-out basis.
>
> To ensure that your writes don't get interleaved with writes from other
> processes, you do need to limit your write sizes to PIPE_BUF or less
> bytes:
>
>   Write requests of {PIPE_BUF} bytes or less shall not be interleaved
>   with data from other processes doing writes on the same pipe. Writes
>   of greater than {PIPE_BUF} bytes may have data interleaved, on
>   arbitrary boundaries, with writes by other processes, whether or not
>   the O_NONBLOCK flag of the file status flags is set.
>
> If you cannot modify the clients, try changing your server to create a
> Unix domain socket instead of a named pipe (the clients shouldn't see
> any difference).
>
> --
> 	Dan Nelson
> 	dnelson@allantgroup.com


Dan,

Thanks for the info, very helpful!  What reference did you get that from? 
I searched high and low to find a definitive answer (like the one above)
before posting.

As for the clients, no, I don't have control over them.  They are web
server child processes, Apache usually.  I considered using a socket, but
I must have missed something since I didn't realize you could have a local
socket that looks and smells like a file to external processes?  Based on
your post, can I assume that I can create a socket that can be accessed
using open() and write() by external processes?

On my way to RTFM... man socket (again...)

Thanks,
Matthew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1720.216.120.158.65.1054573025.squirrel>