Hacker News new | past | comments | ask | show | jobs | submit login

http://udrepper.livejournal.com/20407.html explains the O_CLOEXEC issue.

The solution I have done in my software is to close all unneeded file descriptors right after fork() in the child [1].

It can be argued that this is not the best solution because every place where fork() is called needs to be patched, and this could be in libraries. But the same applies to O_CLOEXEC flags; every place where file descriptors are created needs to be patched. Further, there are probably many more places where fd's are created than where fork() is called.

So if you want to be super careful library, you should do both. Yes, I know the article advises against fork() from libraries. But sometimes you really need it. It's not bad per-se, just bad when done in *nix because of the broken design of OS interfaces.

[1] http://code.google.com/p/badvpn/source/browse/trunk/system/B...

Yeah, and then some other thread opens a file descriptor while your loop is busy closing the last few file descriptors...

CLOEXEC approaches are the only race free solutions.

fork() only leaves the one thread running in the child, and at that point the fd tables are no longer shared, so trying to detect and close unwanted descriptors in the child after fork is not racy by itself as a way of mitigating the possibility of uncontrollable non-CLOEXEC opens elsewhere in the process (though this doesn't preclude it being a bad idea for other reasons).

true, sorry.

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact