[Bug 243177] open(2): Add O_CREATFIFO flag

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243177

--- Comment #4 from Brooks Davis <brooks@FreeBSD.org> ---
I've thought about this some more (and returned from last week's travel).
Consider the following code:

---<cut>---
char path[] = "/some/path";
int fd;
mode_t = 0600;
struct stat sb;

assert(mkfifo(path, mode) == 0);
/* (1) A fifo was created at "/some/path". */
assert((fd = open(path, O_RDWR)) != -1);
/*
 * (2) Some file existed at "/some/path" and was opened.
 * It might or might not be a fifo.
 */
assert(fstat(fd, &sb) == 0 && (sb.st_mode & S_IFMT) == S_IFIFO);
/*
 * (3) The file we opened in (2) was a fifo.
 * "/some/path" might still exist.
 * "/some/path" might be a fifo.
 * "/some/path" might even be the fifo we created.
 */
---<cut>---

With the proposed O_CREATFIFO flag, this would be equivalent to:
---<cut>---
char path[] = "/some/path";
int fd;
mode_t = 0600;
assert((fd = open(path, O_RDWR|O_CREATFIFO|O_EXCL, mode)) != -1);
/*
 * A fifo was created at "/some/path" and we opened it.
 * "/some/path" might still exist.
 * "/some/path" might be a fifo.
 * "/some/path" might even be the fifo we created.
 */
---<cut>---

Closing the race between mkfifo(2) and open(2) saves one or two syscalls in an
uncommon path, but nothing more.  At the end of either snippet, there's no
assurance that some client who opens "/some/path" will open the other end of
the file referred by `fd` because AFACT we can do nothing to guarantee that.  I
can see a symmetry argument for the flag (or a dedicated syscall), but it would
take a real world example or three to convince me there's an interesting race
to close.

-- 
You are receiving this mail because:
You are the assignee for the bug.