[Top][All Lists]

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

Re: [bug-gnulib] wait-process module

From: Derek R. Price
Subject: Re: [bug-gnulib] wait-process module
Date: Wed, 26 Apr 2006 18:41:41 -0400
User-agent: Thunderbird 1.5 (X11/20060313)

Bruno Haible wrote:

> When I say that it is _not_ portable to Windows, I mean the following:
> If someone writes a program that uses the feature, the feature will not work 
> on

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.

> Windows. The 'exitsignal' will always be 0 on Windows, even if the subprocess
> died from an illegal instruction or GFP or Ctrl-Break.

Looking closer at wait-process.c, it looks like WIFSIGNALED & WTERMSIG
*are* defined to return content on Windows.

> 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.  Does this
catch illegal instruction, GFP, or Ctrl-Break?

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

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.

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?


Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 248.835.1260
f: +1 248.835.1263

reply via email to

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