[Top][All Lists]

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

Re: 'make check' from system() under Python

From: Eric Blake
Subject: Re: 'make check' from system() under Python
Date: Sun, 04 Feb 2007 21:45:18 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20061207 Thunderbird/ Mnenhy/

Hash: SHA1

According to Eric Blake on 2/4/2007 9:26 PM:
> Probably something to do with inherited signal handling and python's
> choice of what signals to ignore.  I don't know whether the bug is in
> python for ignoring a signal that the child process expects to normally be
> fatal, or in m4 for not trying to detect the situation of a parent process
> starting it with an unusual signal mask.  But since only python tickles
> the bug, that's where I would send the bug report.

That said, read the comment of the sysval test:

@comment This test has difficulties being portable, even on platforms
@comment where syscmd invokes /bin/sh.  Kill is not portable with signal
@comment names.  According to autoconf, the only portable signal numbers
@comment are 1 (HUP), 2 (INT), 9 (KILL), 13 (PIPE) and 15 (TERM).  But
@comment all shells handle SIGINT, and ksh handles HUP (as in, the shell
@comment exits normally rather than letting the signal terminate it).
@comment Also, TERM is flaky, as it can also kill the running m4 on
@comment systems where /bin/sh does not create its own process group.
@comment That leaves KILL and PIPE as the two signals tested.

I'm thinking that I'll just change the test to use SIGKILL only, since we
have proven that SIGPIPE is risky to rely on portably.  M4 doesn't have a
bug, so much as the testsuite.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

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