All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org
To: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [Bug 95191] New: document behavior of open(2) when path names a fifo with no readers
Date: Sat, 21 Mar 2015 15:16:27 +0000	[thread overview]
Message-ID: <bug-95191-11311@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=95191

            Bug ID: 95191
           Summary: document behavior of open(2) when path names a  fifo
                    with no readers
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
          Reporter: jason.vas.dias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
        Regression: No

linux 3.13 open() , if the path refers to a fifo, and O_WRONLY is set in
its flags , but not O_NONBLOCK, then it does not return until a reader has
connected to the output end of the pipe.

This fact is not documented anywhere in the open(2) manual page - in fact,
it only mentions :

    ENXIO  O_NONBLOCK | O_WRONLY is set, the named file is a FIFO and no
process 
           has the file open for reading.  Or, the file is a device special
file 
           and no corresponding device exists.

You can easily verify this behaviour with bash :

  $ mkfifo /tmp/a.fifo
  $ strace -f bash -c 'echo 1 >/tmp/a.fifo' &
  ...
  open("/tmp/a.fifo", O_WRONLY|O_CREAT|O_TRUNC, 0666
  $ read res </tmp/a.fifo
) = 3
fcntl(1, F_GETFD)                       = 0
fcntl(1, F_DUPFD, 10)                   = 10
fcntl(1, F_GETFD)                       = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
dup2(3, 1)                              = 1
close(3)                                = 0
write(1, "1\n", 2)                      = 2
dup2(10, 1)                             = 1
fcntl(10, F_GETFD)                      = 0x1 (flags FD_CLOEXEC)
close(10)                               = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Please add words to the effect :

  "If the path refers to a named pipe (FIFO), and O_NONBLOCK is not set,
   open() will block until a reader is connected to the write end of the pipe.
  "
to the open(2) manual page.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2015-03-21 15:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-21 15:16 bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r [this message]
     [not found] ` <bug-95191-11311-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
2015-03-21 20:18   ` [Bug 95191] document behavior of open(2) when path names a fifo with no readers bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-21 20:21   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-21 20:29   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-21 20:55   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-21 20:56   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-21 21:16   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-21 21:18   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-22 15:10   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-22 15:15   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
2015-03-23 19:47   ` bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-95191-11311@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon-590eeb7gvniway/ihj7yzeb+6bgklq7r@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.