From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 09:57:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F93937B404 for ; Mon, 2 Jun 2003 09:57:08 -0700 (PDT) Received: from mail.mundomateo.com (24-56-193-117.mdmmi.voyager.net [24.56.193.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD00443F85 for ; Mon, 2 Jun 2003 09:57:06 -0700 (PDT) (envelope-from matthew@mundomateo.com) Received: from mundomateo.com (localhost.mundomateo.com [127.0.0.1]) by mail.mundomateo.com (Postfix) with SMTP id 120115CA2 for ; Mon, 2 Jun 2003 12:57:05 -0400 (EDT) Received: from 216.120.158.65 (SquirrelMail authenticated user matthew) by www.mundomateo.com with HTTP; Mon, 2 Jun 2003 12:57:05 -0400 (EDT) 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> Date: Mon, 2 Jun 2003 12:57:05 -0400 (EDT) From: "Matthew Hagerty" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.0 RC2a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: Re: Are write() calls guaranteed atomic? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: matthew@mundomateo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2003 16:57:08 -0000 > 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