[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] wait-process module

From: Bruno Haible
Subject: Re: [bug-gnulib] wait-process module
Date: Tue, 2 May 2006 15:03:07 +0200
User-agent: KMail/1.5

Derek R. Price wrote:
> Well, I'm using the macros already defined in the wait-process module.
> If WIFSIGNALED and WTERMSIG are returning the wrong values under
> Windows, then the module is already broken because wait_subprocess() is
> defined to exit or return 127 if the child died because of a signal.

These macros are only stubs, substitutes. What I remember from tests a
few years ago is that programs compiled with MSVC do _not_ have an
exit code of 128+signal, like on Unix. I don't remember the details,
but the code of the raise() function in the MSVCRT library (sources
from 1995 as well as the sources from 1997) does this:

int raise(int signum)
      if ( sigact == SIG_DFL ) {

The signal number gets lost; the exit code is always 3.

It is quite likely that the definitions of WTERMSIG, WEXITSTATUS, WIFSIGNALED,
WIFEXITED in wait-process.c are incorrect. This probably results in wrong
error messages ("process XY exited with code Z" instead of
"process XY got fatal signal" or vice versa). But regardless how the
correct definition is, you can never have a WTERMSIG with the same semantics
as on Unix.

> > Which exitsignal does your patch return when the subprocess on Windows
> > died from illegal instruction, GFP or Ctrl-Break?
> When WIFSIGNALED(status) returns true (it will be true if
> WTERMSIG(status) != 0), *exitsignal is set to WTERMSIG(status) before
> exit, which will apparently be ((status) & 0xff) on Windows.

As mentioned above, there is no way to implement WTERMSIG correctly on Woe32.

> >   - The subprocess, as last thing it does in main() before exit(0), sends
> >     to the parent process a bit of information indicating that it succeeded.
> >     This information can take the form of a file that is created or deleted
> >     on the filesystem, or of a particular byte value sent through a file
> >     descriptor to the parent (very easy to do if the subprocess was created
> >     through the pipe() function or equivalent), or similar.

By the way, this is also how the POP3 protocol works: Only after the client
process has said "QUIT", the server process knows for sure that the client
has not died in some strange way, and that it's safe to clear the fetched
mails on the server.

> I'd rather avoid rewriting code in CVS CVS that has worked reliably for
> years, without clear benefit, and CVS does not currently require the
> exit signal functionality under Windows.

If you need a functionality on Unix but not on Windows, you apparently attach
a different meaning to "portability" than the one I try to achieve with
my contributions to gnulib.

> This looks like a simple, non-invasive change to the wait-process module
> to me.  It requires a few more runtime ops, but interferes with the
> previous functionality not at all.  If it isn't currently returning
> signals under Windows and someone needs that functionality, perhaps they
> could add it and submit the patch?

I have nothing against providing a portable API with a Unix implementation,
and the Woe32 implementation comes later. But I refuse an API which is
a priori known to be unimplementable on Woe32 (other than with Cygwin).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]