Re: Are write() calls guaranteed atomic?

From: Matthew Hagerty (matthew_at_mundomateo.com)
Date: 06/02/03

  • Next message: Volker Stolz: "Re: Are write() calls guaranteed atomic?" 
    Date: Mon, 2 Jun 2003 12:57:05 -0400 (EDT)
To: freebsd-hackers@freebsd.org

    > 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

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Volker Stolz: "Re: Are write() calls guaranteed atomic?"

    Relevant Pages

    • Writing a windows service with a socket interface.
      ... I'm writing a windows service that is accessible via sockets. ... and sends a response back to the client. ... Are there any good resources on writing windows services with socket ... Or perhaps if the IP address of the server was modified while the ...
      (microsoft.public.dotnet.framework)
    • Re: Are write() calls guaranteed atomic?
      ... > writing the data have no knowledge of the FIFO, ... 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 ...
      (freebsd-hackers)
    • Re: So, Poll is not scalable... what to do?
      ... >and never need to use poll(). ... By thread pool, do you mean, one thread per socket?, or a work-crew model ... accepted for writing a robust scalable server. ...
      (Linux-Kernel)
    • Sending Binary Data?
      ... My friend and I are writing a chat/IM client in Ruby. ... require 'socket' ... server = TCPServer.new('localhost', port) ... server = TCPSocket.new ...
      (comp.lang.ruby)
    • Re: File that behaves like a socket
      ... the reader, but behaves more like a socket to the writer. ... This has similarities to the way that character-special devices work: they can be read like normal files, but their "server process" has to be in the kernel. ... I had been hoping that Unix-domain sockets would be a solution, but as far as I can see a Unix-domain socket can't be opened like a regular file with open, but rather needs to be opened much like an IP socket with socketand bind. ... The best I have been able to do so far is to use a named pipe, but that is not ideal since the server can't listenfor the named pipe being opened. ...
      (comp.unix.programmer)
    Loading