3 ms·
What about wrapping the first solution into a mutex lock ? Then the multithreaded behavior will disappear. And closing the fd might not be the most frequent ope
by ay 15y ago
What about wrapping the first solution into a mutex lock ? Then the multithreaded behavior will disappear. And closing the fd might not be the most frequent operation usually so should not have much of performance impact.
- JoeAltmaier 15y agoWhich mutex? What about threads you don't 'own', inside libraries for instance? I don't think you will be able to find "one ring to rule them all"
- ay 15y agoOh if they use the close direct, too bad. But libraries that launch the starships behind your back with no control left to you are also not the best gift. Standard's bug aside, I wonder how the practical implementations behave. Is this condition reproducible ?
- eis 15y agoOnly locking the close() is not enough. Another thread could still get the same file descriptor through whatever syscall while you loop around the close(). You would need to lock all syscalls that create or close a file descriptor which is a) infeasable and b) way too slow. In other words: it's a race condition between allocating and deallocating a fd and not between two deallocations.