Date: Mon, 2 Jun 2003 20:29:23 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Matthew Hagerty <matthew@mundomateo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Are write() calls guaranteed atomic? Message-ID: <20030602172923.GA49294@sunbay.com> In-Reply-To: <1720.216.120.158.65.1054573025.squirrel@www.mundomateo.com> References: <1553.216.120.158.65.1054566440.squirrel@www.mundomateo.com> <20030602154917.GA97655@dan.emsphone.com> <1720.216.120.158.65.1054573025.squirrel@www.mundomateo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 02, 2003 at 12:57:05PM -0400, Matthew Hagerty wrote:
> > 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
>=20
>=20
> Dan,
>=20
> Thanks for the info, very helpful! What reference did you get that from?=
=20
> I searched high and low to find a definitive answer (like the one above)
> before posting.
>=20
http://www.unix-systems.org/version3/online.html
--=20
Ruslan Ermilov Sysadmin and DBA,
ru@sunbay.com Sunbay Software Ltd,
ru@FreeBSD.org FreeBSD committer
--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+24lzUkv4P6juNwoRAqqxAJ414mSw/w9m+L2oU4jbQJWoEvxR6ACfTGBj
ho8TiiwyrevJuG72pqbfY90=
=ZLQX
-----END PGP SIGNATURE-----
--qDbXVdCdHGoSgWSk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030602172923.GA49294>