[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: |
Fri, 28 Apr 2006 10:35:42 -0400 |
User-agent: |
Thunderbird 1.5 (X11/20060313) |
Any further comments on this, Bruno?
Derek R. Price wrote:
> 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?
>
> Regards,
>
> Derek
--
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 248.835.1260
f: +1 248.835.1263
<derek@ximbiot.com>