This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: dup_proc_pipe
- From: Christopher Faylor <me at cgf dot cx>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 7 Jan 2005 09:07:46 -0500
- Subject: Re: dup_proc_pipe
- References: <3.0.5.32.20050106224704.0080b480@verizon.net>
- Reply-to: cygwin-developers at cygwin dot com
On Thu, Jan 06, 2005 at 10:47:04PM -0500, Pierre A. Humblet wrote:
> * pinfo.cc (_pinfo::dup_proc_pipe): Can't close proc pipe when
>execing
> or we will suffer an exit code race.
>
>Even when you will wait for yourself, as a top Cygwin process?
Yes this is an issue for an exec from the command line of a windows
process. I'll fix this.
>In the same vein, if the last process in a chain is a Windows
>process, :exit gets called by the Cygwin parent with norecord, so the
>state is not set to PID_EXITED and the logical parent is not alerted.
>It's not critical, but it would be easy to make use of the return
>value of ciresrv.sync, which could be placed in the P_OVERLAY case.
It doesn't look like PID_EXITED gets used for anything really critical
so this isn't a big deal, but you should be able to set this whenever
process exit is detected. I tried the obvious solution of just setting
it in child_info::sync but that is racy. I'm too tired tonight to come
up with a better scenario.
>Also, PID_EXITED is used in the case
>(!created && createit && (procinfo->process_state & PID_EXITED)
>but it's not a sure way of handling the transient because the new
>process may not have access rights to the old pinfo, leading to a
>hard failure. To minimize the likelihood of such an event, one could
>call myself->release () before ExitProcess.
>The order is already optimized in remove_proc.
Ok. I'll add this.
cgf