This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]