Is it suitable to PR upstream as is?

That's a fair question. I have no idea if there's a Windows equivalent, and/or if it's something upstream would even want. (I imagine there are use-cases where you want your child processes to inherit sockets).

Wouldn't using SOCK_CLOEXEC make more sense?

SOCK_CLOEXEC Set the close-on-exec (FD_CLOEXEC) flag on the new file descriptor. See the description of the O_CLOEXEC flag in open(2) for reasons why this may be useful.

It would, but it might not be supported by the crappy old kernels found on our oldest devices (and it might actually make the socket call fail instead of silently ignoring the unknown flag, I can't recall).

So, using fcntl is, unfortunately, a portability necessity.

If I check my notes from the last time I looked into it, as far as Kobo is concerned, it would be safe, the only CLOEXEC compat issue I'm aware of is the lack of support for accept4; open/socket/inotify are OK.

I know that open is NOT okay on legacy Kindle/PB, though, so I'm assuming that's also true of socket there ;).

I would like to revert this on android. See the linked issue. I will check tomorrow that reverting does fix the issue.

Could be interesting to try to just skip the CLOEXEC patch on Android?

In case bionic did a bionic...