[issue8354] siginterrupt with flag=False is reset when signal received

Changes by vila : -- nosy: +vila ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/

[issue8354] siginterrupt with flag=False is reset when signal received

Jean-Paul Calderone added the comment: Should be resolved in, oh, let's see, r81007, r81011, r81016, and r81018. Thanks to everyone who helped out. -- resolution: -> fixed status: open -> closed versions: +Python 3.1 ___ Python tracker

[issue8354] siginterrupt with flag=False is reset when signal received

Jean-Paul Calderone added the comment: I agree that this should be landed (for 2.6 and 2.7). I think I can do it. I made some changes to the tests, though. It would be nice for someone to look those over and make sure the change still looks good. I checked everything in to the siginterrupt

[issue8354] siginterrupt with flag=False is reset when signal received

Martin added the comment: This patch has been reviewed by both Andrew and myself, it would be nice if someone made the time to land it. The test change is unlikely to break anything, and hey, that's what buildbots are for. -- nosy: +gz ___ Python t

[issue8354] siginterrupt with flag=False is reset when signal received

Andrew Bennetts added the comment: > I'm not exactly sure how we will know if it is expected to fail, > though. I don't think `HAVE_SIGACTION` is exposed nicely to Python > right now. It might be useful to have the contents of pyconfig.h exposed as a dict somehow. Maybe call it sys._pyconfig

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: > * There seems to be no good reason to special case SIGCHLD in signal_handler. > The comment about infinite recursion has no obvious interpretation to me. > Fortunately, this is irrelevant on platforms with sigaction, because the > handler remains

[issue8354] siginterrupt with flag=False is reset when signal received

Jean-Paul Calderone added the comment: > Will the modified test fail on platforms that don't define HAVE_SIGACTION? Only if they also have siginterrupt, which seems unlikely (as neologix explained). The implemented behavior on such platforms is unmodified from current trunk, while the test r

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: Well, I just think that the probability of having siginterrupt without sigaction is far less than having a Unix system without siginterrupt (which the current test_signal assumes). Or just drop the patch for the test, it honestly doesn't bother me ;-

[issue8354] siginterrupt with flag=False is reset when signal received

R. David Murray added the comment: Yes, my question was directed at finding out if there were any platforms on which we'd have to add an additional skip (which would mean refactoring that test into two tests). But if the buildbots are all happy after it is applied we can probably choose to n

[issue8354] siginterrupt with flag=False is reset when signal received

Andrew Bennetts added the comment: FWIW, comparing the "change history" sections of and suggests that sigaction predates siginterrupt, but it's

[issue8354] siginterrupt with flag=False is reset when signal received

Andrew Bennetts added the comment: Are there any platforms that define HAVE_SIGINTERRUPT but that do not define HAVE_SIGACTION? If there are, then yes I expect they would fail that test. It would be a shame to delay this fix just because it doesn't fix all platforms... is it possible to mark

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: > Will the modified test fail on platforms that don't define HAVE_SIGACTION? Well, in theory, if the system has siginterrupt but not sigaction, it will fail. But as said, I don't think it's possible, see man siginterrupt: " This library routine u

[issue8354] siginterrupt with flag=False is reset when signal received

R. David Murray added the comment: Will the modified test fail on platforms that don't define HAVE_SIGACTION? -- nosy: +r.david.murray ___ Python tracker ___

[issue8354] siginterrupt with flag=False is reset when signal received

Andrew Bennetts added the comment: Your patches look good to me. (They don't fix platforms without sigaction, but as you say they probably don't have siginterrupt, and even if they do they will still have an unfixable race.) What's the next step? I can't see an button to add this issue to th

[issue8354] siginterrupt with flag=False is reset when signal received

Changes by Ezio Melotti : -- keywords: +needs review priority: -> normal stage: -> patch review ___ Python tracker ___ ___ Python-bug

[issue8354] siginterrupt with flag=False is reset when signal received

Changes by Charles-Francois Natali : Added file: http://bugs.python.org/file16848/signal_noreinstall.diff ___ Python tracker ___ ___ Python-bug

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: Attached are two patches: - test_signal_siginterrupt.diff is a patch for Lib/test/test_signal.py to check for this problem (more than one signal received after calling signal.siginterrupt()) before: $ ./python Lib/test/regrtest.py test_signal test_sig

[issue8354] siginterrupt with flag=False is reset when signal received

Charles-Francois Natali added the comment: > The effect of signal.siginterrupt(somesig, False) is reset the first time a > that signal is received. This is not the documented behaviour, and I do not > think this is a desireable behaviour. It renders siginterrupt effectively > useless at pro

[issue8354] siginterrupt with flag=False is reset when signal received

Changes by Antoine Pitrou : -- nosy: +exarkun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8354] siginterrupt with flag=False is reset when signal received

New submission from Andrew Bennetts : The effect of signal.siginterrupt(somesig, False) is reset the first time a that signal is received. This is not the documented behaviour, and I do not think this is a desireable behaviour. It renders siginterrupt effectively useless at providing the rob