3 ms·
> True, so you fflush before dup2. Assuming you know exactly what buffering everything in the process does. But you just mentioned a case of something that "ha
by JoshTriplett 7y ago
> True, so you fflush before dup2.
Assuming you know exactly what buffering everything in the process does. But you just mentioned a case of something that "happens deep inside a library".
I absolutely agree that dup2 should be possible; I only mentioned that replacing a "live" file descriptor isn't necessarily simple (unless your program is currently quiesced).
- asveikau 7y ago> But you just mentioned a case of something that "happens deep inside a library". Well, if we're talking C, if you have the same libc as all your libraries [not true on Win32, but true on recent popular Unix-like OSs], you should be able to safely fflush and dup2, then call into any applicable library code ... But anyway, I think the difficulties with it are much larger in the kernel than in user land. I could very well imagine a scenario in which supporting dup2(2) required more locking and reference counting of kernel objects. I.e. any kernel thread currently operating against the data structure backing a descriptor must have that operation survive a dup2.