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: snapshot 20050114 race (on list)


On Sat, Jan 22, 2005 at 06:04:01PM -0500, Pierre A. Humblet wrote:
>At 04:35 PM 1/22/2005 -0500, Christopher Faylor wrote:
>>On Sat, Jan 22, 2005 at 04:28:13PM -0500, Christopher Faylor wrote:
>>>On Sat, Jan 22, 2005 at 04:25:28PM -0500, Christopher Faylor wrote:
>>>>On Mon, Jan 17, 2005 at 10:25:51PM -0500, Pierre A. Humblet wrote:
>>>>>At 10:15 PM 1/17/2005 -0500, you wrote:
>>>>>>On Mon, Jan 17, 2005 at 09:30:11PM -0500, Pierre A. Humblet wrote:
>>>>>>>It's not a Cygwin handle.  It's an internal Windows handle to the
>>>>>>>current working directory.  Ah! Doing a chdir to C:\ just before
>>>>>>>alerting would fix this, except in the case of being terminated.
>>>>>>
>>>>>>If the process is terminated wouldn't this be a non-issue?
>>>>>
>>>>>It depends on the timing between the pipe being closed by Windows
>>>>>and the cwd handle being closed. This won't keep me awake.
>>>>
>>>>I put the SetCurrentDirectory suggestion into the latest cygwin but it
>>>>just occurred to me that this needs to be called unconditionally since
>>>>an execed child could exit prior to the stub exiting so, something like:
>>>>
>>>>  int bar;
>>>>  mkdir ("/foo", 0777);
>>>>  chdir ("/foo");
>>>>  if (!fork ())
>>>>    exec ("/bin/pwd");
>>>>  wait (&bar);
>>>>  chdir ("/");
>>>>  rmdir ("/foo");
>>>>
>>>>wouldn't be guaranteed to work since there could be a stub that was
>>>>still cd'ed to "/foo" even after "/bin/pwd" has finished executing.
>>>
>>>Oh *@#$%!
>>>
>>>Keeping the SetCurrentDirectory in exit won't work.  It has to happen
>>>prior to the exec or there's still a race.
>>
>>...but if you do it before the exec you'll screw up native windows
>processes...
>>
>>Ah, the fun.
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
>e/createprocess.asp
>
>lpCurrentDirectory
>    [in] Pointer to a null-terminated string that specifies the full path
>to the current directory for the process. The string can also specify a UNC
>path.
>
>    If this parameter is NULL, the new process will have the same current
>drive and directory as the calling process. (This feature is provided
>primarily for shells that need to start an application and specify its
>initial drive and working directory.)
>lpStartupInfo

Yes!  That would do it.  I'd forgotten about that.  Thanks.

As it turns out, my concerns were somewhat overblown because you just
have to make sure that you reset current directory while you still are
in possession of the write pipe.  That's no problem, as it turns out.

cgf


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