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 gslavin
Recipients Andre Merzky, eryksun, gslavin
Date 2016-09-06.07:46:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAPedJr4HzaSf6R3f4OKWRQ-D=PArh3baKfjZNyLn5fFWPTd5iA@mail.gmail.com>
In-reply-to <1473147307.47.0.188957894652.issue27889@psf.upfronthosting.co.za>
Content
The docs say the sleep call will end if a signal is caught, so once the
main thread wakes, it won't go back to sleep.

On Sep 6, 2016 12:35 AM, "Andre Merzky" <report@bugs.python.org> wrote:

>
> Andre Merzky added the comment:
>
> Hi George,
>
> > From these results, it appears there is no guarentee that the signal
> handler will run before the main thread continues execution at the
> time.sleep(500) line.  This would explain why we advance to the else clause
> before the exception is raised.
>
> To me it looks like the problem pops up *way* before the `sleep(100)` (or
> whatever) finishes, in fact it looks consistently like the sleep is indeed
> interrupted after one second.  I would it thus interpret differently, as
> the code should not be able to advance to the `else` clause at that time.
>
> Is that different for you?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27889>
> _______________________________________
>
History
Date User Action Args
2016-09-06 07:46:28gslavinsetrecipients: + gslavin, eryksun, Andre Merzky
2016-09-06 07:46:28gslavinlinkissue27889 messages
2016-09-06 07:46:28gslavincreate