This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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"
History
Date User Action Args
2011-06-29 07:29:10neologixsetrecipients: + neologix, vstinner, giampaolo.rodola, rosslagerwall, python-dev
2011-06-29 07:29:09neologixlinkissue12303 messages
2011-06-29 07:29:09neologixcreate