delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/07/31/22:30:12

From: TYann AT vet DOT com DOT au (Trevor Yann)
Subject: spawn problems (windows 98?)
31 Jul 1998 22:30:12 -0700 :
Message-ID: <3.0.5.32.19980801150439.007cd430.cygnus.cygwin32.developers@mail.mel.cybec.com.au>
Mime-Version: 1.0
To: cygwin32-developers AT cygnus DOT com

I have been testing a change to bash that will call spawn instead of
fork/exec under some circumstances. Initial tests running configure for
patch-2.5.3 indicate that modified bash is faster than ash.

There are two problems that I have found:

1. bash thinks that the child process has finished when it has not.

2. occasional temporary system hangs, followed by a timeout in
WaitForSingleObject.

Note that when I have no problems when either ash or the b19 bash are
installed as /bin/sh.exe. 

In general the cygwin environment appears to be quite stable under Windows
98 - I have been able to bootstrap a recent snapshot of egcs without any
trouble.

I am going to attempt to create a test program for the problems - a hacked
bash is hardly a simple test program.


Problem 1: thinks that the child process has finished when it has not
---------------------------------------------------------------------

I have been running the following command with my modified bash installed
as /bin/sh.exe:

	time ../patch-2.5.3/configure -v

The bash prompt, along with time details are always output before the
configure has completed:

checking for d_ino member in directory struct... yes
creating ./config.status

real    3m52.280s
user    0m0.000s
sys     0m0.000s
BASH.EXE-2.01$ creating Makefile
creating config.h



Problem 2: occasional temporary system hangs
--------------------------------------------

Occasionally the configure that I run will hang. The entire computer
appears to be locked - it will not even respond to ctrl-alt-delete. If I
leave the system for a couple of minutes, it resumes. Following is a
fragment of the output from the configure, including output from the cygwin
dll.

checking return type of signal handlers...
(D:\CYGNUS\B19\H-I386-CYGWIN32\BIN\SH.EXE 14371) block_sig_dispatch:
WFSO(sig_dispatch<0x2C>) failed, error = 0
(D:\CYGNUS\B19\H-I386-CYGWIN32\BIN\SH.EXE 14371) block_sig_dispatch:
WFSO(sig_dispatch<0x2C>) failed, error = 0
(D:\CYGNUS\B19\H-I386-CYGWIN32\BIN\SH.EXE 14371) lock_cs: WFSO(cs), rc 258,
error 288
void


My environment
--------------

I have been running with a cygwinb19.dll built from the winsup-980709
snapshot, using the egcs 1.02 compiler, with Windows 98.

My pc is 120Mhz pentium.

This is the change in bash (2.02.1) that I have been testing:


diff -upr bash-2.02.1.original/execute_cmd.c bash-2.02.1/execute_cmd.c
--- bash-2.02.1.original/execute_cmd.c	Sat Jul 11 01:49:08 1998
+++ bash-2.02.1/execute_cmd.c	Sat Aug 01 10:19:08 1998
@@ -66,6 +66,11 @@
 #  include <sys/times.h>
 #endif
 
+#ifdef __CYGWIN32__
+/* for spawn */
+#  include <process.h>
+#endif
+
 #include <errno.h>
 
 #if !defined (errno)
@@ -2966,6 +2971,27 @@ execute_disk_command (words, redirects, 
      don't bother to fork, just directly exec the command. */
   if (nofork && pipe_in == NO_PIPE && pipe_out == NO_PIPE)
     pid = 0;
+#ifdef __CYGWIN32__
+  else if (pipe_in == NO_PIPE && pipe_out == NO_PIPE &&
+	     !redirects && !async)
+    {
+	  int max_fd = fds_to_close ? fds_to_close->size : 0;
+	  int fd;
+
+      args = word_list_to_argv (words, 0, 0, (int *)NULL);
+
+      for (fd = 0; fd < max_fd; fd++)
+		if (fds_to_close->bitmap[fd])
+		  SET_CLOSE_ON_EXEC(fd);
+
+      pid = _spawnv (_P_NOWAIT, command, args);
+
+      for (fd = 0; fd < max_fd; fd++)
+		if (fds_to_close->bitmap[fd])
+		  SET_OPEN_ON_EXEC(fd);
+    }
+#endif
   else
     pid = make_child (savestring (command_line), async);
 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019