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)


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). 

Pierre



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