Re: snapshot 20050114 race (on list)

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

At 08:38 PM 1/17/2005 -0500, you wrote:
>On Mon, Jan 17, 2005 at 08:30:37PM -0500, Pierre A. Humblet wrote:
>>At 02:24 PM 1/16/2005 -0500, Pierre A. Humblet wrote:
>>>I have been trying without success to reproduce the race
>>>reported by Eric Blake, which started this thread.
>>
>>I tried again, with the latest cvs, trying to prove that
>>"touch" lingers in the directory being removed.
>>I still can't reproduce it, but I can get something similar.
>>
>>Consider:
>>C:~: exim 2>/dev/null; ps; ps -W
>>      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>>     2800       1    2800       2800  con 1003 19:26:15 /c/Program
>>Files/cygwin/bin/rxvt
>>     2632    2800    2632       1448    0 1003 19:26:15 /usr/bin/bash
>>     3548    2632    3548       2448    0 1003 20:03:33 /usr/bin/ps
>>      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>>        4       0       0          4    ?    0 15:24:48 *** unknown ***
>> <snip>
>>     3544       0       0       3544    ?    0 20:03:34
>>C:\progra~1\cygwin\bin\exim-4.43-2.exe
>>     4044       0       0       4044    ?    0 20:03:34
>>C:\progra~1\cygwin\bin\ps.exe
>>
>>We see that Exim persists as a Windows process long after
>>( > two forks and two spawns ) it is gone as a Cygwin process. 
>>
>>To exhibit the phenomenon reported by Eric, you have to know that exim
>>cd's to /var/spool/exim, creating it if needed. Sure enough:
>>
>>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>>rmdir: `/var/spool/exim': Device or resource busy
>>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>>rmdir: `/var/spool/exim': Device or resource busy
>>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>>rmdir: `/var/spool/exim': Device or resource busy
>>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>>rmdir: `/var/spool/exim': Device or resource busy
>>C:~: exim 2>/dev/null; sleep 1; rmdir /var/spool/exim
>>C:~: exim 2>/dev/null; sleep 1; rmdir /var/spool/exim
>>C:~: 
>>
>>Not sure why exim lingers for so long. Perhaps because it uses many dlls.
>>I tried with a few other programs without "success". 
>>
>>Perhaps removing the alert_parent(0) would alleviate the race, but the
>>only safe way is a WaitFor(hProcess). 
>
>You still haven't explained why are there still open handles at the
>point where the alert_parent is called.  If that is the case then there
>is apparently something wrong in cygwin since all handles are supposed
>to be closed at this point.

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.

Pierre