Message139398
| Author |
neologix |
| Recipients |
giampaolo.rodola, neologix, python-dev, rosslagerwall, vstinner |
| Date |
2011年06月29日.07:29:09 |
| SpamBayes Score |
0.00071199914 |
| Marked as misclassified |
No |
| Message-id |
<BANLkTimHX7WevveY9Y9-6+WJh8Z2fj9M4w@mail.gmail.com> |
| In-reply-to |
<1309220753.88.0.301103656267.issue12303@psf.upfronthosting.co.za> |
| Content |
> 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 of http://bugs.python.org/issue8407#msg138066
But I think we could just remove this test: honestly, I'm not sure
that checking the behavior in case of delivery of an unblocked signal
is really useful, especially since the behavior is not clearly
defined, see POSIX man page:
"""
The sigwaitinfo() and sigtimedwait() functions may fail if:
[EINTR]
The wait was interrupted by an unblocked, caught signal. It will be
documented in system documentation whether this error will cause these
functions to fail.
"""
"may fail" [...] "It will be documented in system documentation" |
|