unix: simplify uv__cloexec_fcntl() #3492
Conversation
FD_CLOEXEC is the only defined flag for fcntl(F_SETFD) so don't bother getting the status of that flag first with fcntl(F_GETFD), just set it.
|
Not to my knowledge and I think it's highly unlikely. FD_CLOEXEC being the sole flag is one of those bits of UNIX lore that's been around so long it's entrenched. |
|
True, but we also pretty much only use this code path on weird platforms (e.g. not AIX, Apple, other BSDs, or linux) |
|
I suppose so1 and I don't feel too strongly but this set-and-forget idiom is widespread enough (random example: nginx) that I'm confident it's safe, even on obscure platforms. 1 As of #3257 it's called directly from src/unix/process.c for reasons I'm not wholly clear on. |
|
It is from #1167, since calling ioctl is not required to be safe to call after fork. (see man 7 signal-safety and man 2 fork). But also the only reason we use the ioctl is to avoid the need for 2 syscalls here. StackOverflow seems to think that fcntl might be a better choice always, and we can also now eliminate the ioctl (https://stackoverflow.com/a/1151077/1712368) for this. See also #1832. |
Now that uv__cloexec_fcntl() is simplified (libuv#3492), there is no benefit to maintaining duplicate code paths for the same thing.
Now that uv__cloexec_fcntl() is simplified (#3492), there is no benefit to maintaining duplicate code paths for the same thing.
FD_CLOEXEC is the only defined flag for fcntl(F_SETFD) so don't bother getting the status of that flag first with fcntl(F_GETFD), just set it.
Now that uv__cloexec_fcntl() is simplified (libuv#3492), there is no benefit to maintaining duplicate code paths for the same thing.
FD_CLOEXEC is the only defined flag for fcntl(F_SETFD) so don't bother
getting the status of that flag first with fcntl(F_GETFD), just set it.
cc @vtjnash - as mentioned in #3490