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).
> 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.
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).