More changes for bug 411

[Jilles Tjoelker]

Hi,

I found some issues in bug411_atomic_CLOEXEC.pdf.

On page 2, there is
accept4(sock, addr, len, O_NONBLOCK)
which should at least be (but see below)
accept4(sock, addr, len, SOCK_NONBLOCK)
(Note that this mistake will not be detected on Linux/glibc because the
values are equal; however, on FreeBSD, the value of O_NONBLOCK is 4 and
the value of SOCK_SEQPACKET is 5, so SOCK_NONBLOCK cannot be equal to
O_NONBLOCK.)

Although O_NONBLOCK is the most common property where the difference is
apparent, BSD copies a few more properties to the new socket: the
O_ASYNC property and the signal destination as set by fcntl(F_SETOWN).
The latter property is also part of POSIX. In the FreeBSD
implementation, this only applies to accept(); accept4() does not copy
these properties, like Linux. As a result, accept4() is as portable as
possible but accept() is not exactly equivalent to any form of
accept4().

Furthermore, there is
Also, I don't know of any platform where
posix_spawn_file_actions_adddup2( ) can clear FD_CLOEXEC,
but posix_spawn_file_actions_adddup2() has in fact behaved that way in
FreeBSD's implementation since it was first committed (though this was
not documented until later).

[Eric Blake]

Post by Jilles Tjoelker
Hi,
I found some issues in bug411_atomic_CLOEXEC.pdf.
On page 2, there is
accept4(sock, addr, len, O_NONBLOCK)
which should at least be (but see below)
accept4(sock, addr, len, SOCK_NONBLOCK)
(Note that this mistake will not be detected on Linux/glibc because the
values are equal; however, on FreeBSD, the value of O_NONBLOCK is 4 and
the value of SOCK_SEQPACKET is 5, so SOCK_NONBLOCK cannot be equal to
O_NONBLOCK.)

Thanks; I'll fix that.

Post by Jilles Tjoelker
Although O_NONBLOCK is the most common property where the difference is
apparent, BSD copies a few more properties to the new socket: the
O_ASYNC property and the signal destination as set by fcntl(F_SETOWN).

O_ASYNC is a non-POSIX extension, so portable programs aren't using it
anyways. The signal destination on the other hand might be something to
consider adding some documentation.

Post by Jilles Tjoelker
The latter property is also part of POSIX. In the FreeBSD
implementation, this only applies to accept(); accept4() does not copy
these properties, like Linux. As a result, accept4() is as portable as
possible but accept() is not exactly equivalent to any form of
accept4().

What's the best solution for this, just documenting that the signal
destination of accept() is unspecified on whether it is inherited or
reset by accept()?

Post by Jilles Tjoelker
Furthermore, there is
Also, I don't know of any platform where
posix_spawn_file_actions_adddup2( ) can clear FD_CLOEXEC,
but posix_spawn_file_actions_adddup2() has in fact behaved that way in
FreeBSD's implementation since it was first committed (though this was
not documented until later).

Okay, I can tweak that wording - the fact that we have a pre-existing
example makes the argument stronger for mandating the behavior.

[Jilles Tjoelker]

Post by Eric Blake

Post by Jilles Tjoelker
Although O_NONBLOCK is the most common property where the difference is
apparent, BSD copies a few more properties to the new socket: the
O_ASYNC property and the signal destination as set by fcntl(F_SETOWN).

O_ASYNC is a non-POSIX extension, so portable programs aren't using it
anyways. The signal destination on the other hand might be something to
consider adding some documentation.

Post by Jilles Tjoelker
The latter property is also part of POSIX. In the FreeBSD
implementation, this only applies to accept(); accept4() does not copy
these properties, like Linux. As a result, accept4() is as portable as
possible but accept() is not exactly equivalent to any form of
accept4().

What's the best solution for this, just documenting that the signal
destination of accept() is unspecified on whether it is inherited or
reset by accept()?

Yes, together with some text that accept4() does not copy the signal
destination.

If other implementations don't agree, writing the behaviour down
precisely should help discovering this earlier rather than later.

[Rich Felker]

Post by Eric Blake

Post by Jilles Tjoelker
Hi,
I found some issues in bug411_atomic_CLOEXEC.pdf.
On page 2, there is
accept4(sock, addr, len, O_NONBLOCK)
which should at least be (but see below)
accept4(sock, addr, len, SOCK_NONBLOCK)
(Note that this mistake will not be detected on Linux/glibc because the
values are equal; however, on FreeBSD, the value of O_NONBLOCK is 4 and
the value of SOCK_SEQPACKET is 5, so SOCK_NONBLOCK cannot be equal to
O_NONBLOCK.)

Thanks; I'll fix that.

Post by Jilles Tjoelker
Although O_NONBLOCK is the most common property where the difference is
apparent, BSD copies a few more properties to the new socket: the
O_ASYNC property and the signal destination as set by fcntl(F_SETOWN).

O_ASYNC is a non-POSIX extension, so portable programs aren't using it
anyways. The signal destination on the other hand might be something to
consider adding some documentation.

Note that socket options like receive timeout also seem to be
unspecified as to whether they're inherited. See this open question:

http://stackoverflow.com/questions/5968132/are-socket-options-inherited-across-accept-from-the-listening-socket

Post by Eric Blake

Post by Jilles Tjoelker
Furthermore, there is
Also, I don't know of any platform where
posix_spawn_file_actions_adddup2( ) can clear FD_CLOEXEC,
but posix_spawn_file_actions_adddup2() has in fact behaved that way in
FreeBSD's implementation since it was first committed (though this was
not documented until later).

Okay, I can tweak that wording - the fact that we have a pre-existing
example makes the argument stronger for mandating the behavior.

That behavior would be nice -- right now it's a real pain to use
posix_spawn correctly since all file descriptors must be FD_CLOEXEC in
the parent (for safety against fd leaks) and you have to ensure that
they "start out" on different fd numbers than their final destinations
so that the file actions can produce a result that's not FD_CLOEXEC.

Rich