[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Ross Lagerwall added the comment: The tests seem to be working fine on all the buildbots now... Thanks! -- resolution: -> accepted stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

STINNER Victor added the comment: > But I think we could just remove this test The test pass on Linux and FreeBSD 6 using a subprocess. I commited my patch to replace fork() by subprocess, let's see how it works on buildbots. -- ___ Python tracker

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Roundup Robot added the comment: New changeset 00ca0c2c7bc0 by Victor Stinner in branch 'default': Issue #12303: run sig*wait*() tests in a subprocesss http://hg.python.org/cpython/rev/00ca0c2c7bc0 -- ___ Python tracker

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Charles-François Natali added the comment: > Oh, the problem is that sigwait() behaviour changes after a fork: it is > interrupted if an unexpected signal is received, but the signal handler is > not called. It behaves correctly (the signal handler is called) without the > fork. > Reminds me

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

STINNER Victor added the comment: > test_sigwaitinfo_interrupted() fails because SIGALRM > signal handler is called ... Oh, the problem is that sigwait() behaviour changes after a fork: it is interrupted if an unexpected signal is received, but the signal handler is not called. It behaves cor

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

STINNER Victor added the comment: > @Victor, you've had some experience with fixing signals > on the FreeBSD 6 buildbot... It's not exactly that I had some experience, it's just that I have a SSH access to the buildbot. The following code hangs for (exactly?) 30 seconds on sigwaitinfo():

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Ross Lagerwall added the comment: >From the FreeBSD 6.4 buildbot: """ [172/356/2] test_signal error: 'NoneType' object has no attribute 'si_signo' error: False is not true test test_signal failed -- multiple errors occurred; run in verbose mode for details Re-running test test_signal in verbose

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Roundup Robot added the comment: New changeset 768234f5c246 by Ross Lagerwall in branch 'default': Fix test_signal on Windows after #12303. http://hg.python.org/cpython/rev/768234f5c246 -- ___ Python tracker _

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Roundup Robot added the comment: New changeset 1137f7021b95 by Ross Lagerwall in branch 'default': Issue #12303: Add sigwaitinfo() and sigtimedwait() to the signal module. http://hg.python.org/cpython/rev/1137f7021b95 -- nosy: +python-dev ___ Python

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

STINNER Victor added the comment: > If this is OK, I'll commit the patch. Yep, this version is the good one. Please keep the issue open until the test pass on all buildbots. Each newly added signal functions took me some days to fix the test for Mac OS X and/or FreeBSD 6. But you are maybe mo

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Ross Lagerwall added the comment: > What do you mean? signal.SIGPOLL exists in Python 3.3. Right, si_band added. > - test_sigwaitinfo(), test_sigtimedwait_poll(), > test_sigwaitinfo_interrupted() are called from a child process. In > test_wait(), I chose to write manually to stdout and call

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

STINNER Victor added the comment: >> It is possible to pass a negative timeout > It now raises an exception like select. Great. >> According to the manual page, sigwaitinfo() or sigtimedwait() >> can be interrupted (EINTR) > Actually, PyErr_SetFromErrno() does this implicitly. I added a test

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Ross Lagerwall added the comment: Thanks for the review. > Why do you wait until the end of PyInit_signal() to set initialized to 1? Fixed. > If this variable is only present ... but I see that the init function of the > posixmodule.c has also a static initialized variable. I simply followed

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

STINNER Victor added the comment: Cool, a patch! "Some" comments. Why do you wait until the end of PyInit_signal() to set initialized to 1? If this variable is only present to call PyStructSequence_InitType() only once, you can set initialized to 1 directly in the if. Is it possible that PyI

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Ross Lagerwall added the comment: Here's a patch to add the two functions (with docs and tests). You'll need to run autoreconf before compiling. -- assignee: -> rosslagerwall keywords: +patch nosy: +rosslagerwall stage: -> patch review type: -> feature request Added file: http://bug

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

New submission from STINNER Victor : Python 3.3 adds timeout arguments to communicate() and wait() methods of subprocess.Popen, acquire() method of threading.Lock, and maybe more. I like (optional) timeouts, and so it would be nice to have sigtimedwait(). If we expose sigtimedwait(), it's triv