This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: More spawn & Windows processes
At 11:18 AM 12/27/2004 -0500, Christopher Faylor wrote:
>On Mon, Dec 27, 2004 at 11:07:49AM -0500, Pierre A. Humblet wrote:
>>At 11:05 AM 12/27/2004 -0500, Christopher Faylor wrote:
>>>On Mon, Dec 27, 2004 at 10:51:58AM -0500, Pierre A. Humblet wrote:
>>>> should now be able to save microseconds by simply closing the pipe.
>>>
>>>Did you happen to notice that it *used* to be a CloseHandle?
>>
>>Yes. I think you changed it in an attempt to make P_DETACH work.
>
>No. I remember that you floated that theory but it really had nothing
>to do with that. I wanted to guarantee that the parent process saw a
>"close" regardless of whether there were other processes with the pipe
>open. It's a paranoia thing as I round onto releasing 1.5.13.
OK. At the time you made it, the change was in fact necessary because
there could be another process with the pipe open (a detached process).
Now there can't be other processes with the pipe open (except the
parent, during an unlikely transient), and you keep the change due
a paranoia thing.
To save us (the original reason), it would be best to revert to
closing the pipe.
Meanwhile I had a second look at the hang in
strace sh -c cygcheck
It does not always happen. It happens only when the exec'ed process
runs faster than the exec'ing process, as in the following trace
175 563595 [main] sh 1014051! spawn_guts: new process name c:\progra~1\cygwin\bin\cygcheck.exe
Usage: cygcheck [OPTIONS] [PROGRAM...]
Check system information or PROGRAM library dependencies
-c, --check-setup check packages installed via setup.exe
-d, --dump-only no integrity checking of package contents (requires -c)
-s, --sysinfo system information (not with -k)
-v, --verbose verbose output (indented) (for -[cfls] or programs)
-r, --registry registry search (requires -s)
-k, --keycheck perform a keyboard check session (not with -[scfl])
-f, --find-package find installed packages containing files (not with -[cl])
-l, --list-package list the contents of installed packages (not with -[cf])
-h, --help give help about the info (not with -[cfl])
-V, --version output version information and exit
You must at least give either -s or -k or a program name
5718 569313 [main] sh 1014051! close_all_files: closing fd 0
3898 573211 [main] sh 1014051! close_all_files: closing fd 1
297 573508 [main] sh 1014051! close_all_files: closing fd 2
952 574460 [main] sh 1014051! _pinfo::dup_proc_pipe: closed wr_proc_pipe 0x4 for pid 1014051(4293972685)
209 574669 [main] sh 1014051! spawn_guts: spawned windows pid -994611
495 575164 [main] sh 1014051! child_info::sync: waiting for subproc_ready(0x90) and child process(0x110)
200 575364 [main] sh 1014051! child_info::sync: non-cygwin exit value is 0x1
385 575749 [main] sh 1014051! sigproc_terminate: entering
187 575936 [main] sh 1014051! proc_terminate: nprocs 0
The mindboggling line is
_pinfo::dup_proc_pipe: closed wr_proc_pipe 0x4 for pid 1014051(4293972685)
It indicates that it's apparently possible to successfully duplicate a pipe into
a process that has exited! That open pipe is keeping the original sh waiting for
the "termination" of its child.
Pierre