Greg Hudson wrote:
> On Sun, 2004-09-05 at 19:52, Branko Čibej wrote:
>>> I didn't think Windows really had the concept of file descriptors
>>> outside of the POSIX terarium, much less file descriptors which (by
>>> virtue of their numbers) map onto stdin/stdout/stderr.
>
>> Windows has all of that, even though it's simulated by the C runtime
>> library. That's why I'd like to see proof (either through testing, or
>> BDB code review) that this problem really doesn't occur on Windows
...
> On Unix, the bindings of fds 0/1/2 at process startup are purely in the
> hands of the calling process; the fork() and exec() calls don't care
> about them. In the Windows world,
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
> and
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/startupinfo_str.asp
> suggest that there is much more structure involved. I don't know what
> happens if you pass INVALID_HANDLE_VALID in the startup info structure,
> but it seems likely that Windows will do something intelligent (either
> mapping that file handle to the console, or mapping it to a null
> device).
I ran some tests.
Within a single process, it is possible to close standard fds, and have a
subsequent open() return 0/1/2.
However, if you exec a subprocess, open()-ed fds start from 3.
Also, despite playing around with several invocations of CreateProcess, I
was unable create a situation without preopened 0/1/2.
Nevertheless, I wonder whether we should enable the code on Windows anyway,
in case there is some strange set of circumstances that can cause the
problem. Three stat() calls shouldn't be vastly expensive, after all.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
- application/octet-stream attachment: winfds.c
Received on Mon Sep 6 07:42:46 2004