classification
Title: Rewrite InterProcessSignalTests
Type: Stage:
Components: Tests Versions: Python 3.3
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: neologix, vstinner
Priority: normal Keywords:

Created on 2011-07-04 22:33 by vstinner, last changed 2013-01-03 01:20 by vstinner. This issue is now closed.

Messages (2)
msg139813 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-07-04 22:33
InterProcessSignalTests uses 4 different signal handlers (SIGUSR1, SIGUSR2, SIGALRM, SIGHUP) and uses 2 methods to raise a signal (a subprocess executing "kill -SIG pid" or signal.alarm(1)). It uses signal.pause() and/or time.sleep(1) to wait the signal, or just nothing for SIGUSR2 (configured to be ignored).

The testcase tests too many unrelated things.

signal.alarm(1) is not an interprocess signal: it is a signal send to the process itself.

Why using two different signal handlers? A modifies a_called, B modifies b_called but raise also a Python exception. How is it related to interprocess signal handling?

Why checking that the handler A (SIGHUP) has not been called when the signal handler B (SIGUSR1) is called?

Why is the garbage collector disabled?

I propose to write a new simple testcase: install a signal handler raising a Python exception, send a signal using a child process, ensure that the signal has been received (wait for the exception). Pseudo-code:

--------
s = signal.SIGUSR1
def handler(signum, frame): 1/0
signal.signal(s, handler)
try:
  subprocess.call([sys.executable, '-c', '... kill(%s, %s)' % (os.getpid(), s))
  ... wait the signal ...
except ZeroDivisionError:
  pass
else:
  raise Exception("ZeroDivisionError not raised"
--------

The whole test has to be run in a subprocess.

The new test may pass on freebsd 6, it should be checked (see issue #12469).
msg178875 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-01-03 01:20
I don't want to work on signals anymore, and nobody looks to be interested, so I'm closing this issue.
History
Date User Action Args
2013-01-03 01:20:43vstinnersetstatus: open -> closed
resolution: wont fix
messages: + msg178875
2011-07-04 22:33:20vstinnercreate