Message 411371 - Python tracker

➜

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	vstinner
Recipients	Mark.Shannon, corona10, eric.snow, gvanrossum, kj, vstinner
Date	2022-01-23.13:52:56
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1642945976.74.0.535147024255.issue46465@roundup.psfhosted.org>
In-reply-to

Content
> Signal handling in Python is asynchronous. https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers See my previous comment: "CHECK_EVAL_BREAKER() matters for signals, but also multithreading (drop the GIL), asynchronous exception and pending calls." If a thread executes a function which only uses opcodes which don't call CHECK_EVAL_BREAKER(), I understand that it can eat more than its slice of 5 ms, see sys.getswitchinterval(): https://docs.python.org/dev/library/sys.html#sys.getswitchinterval So it's also a threads scheduling issue, no?

> Signal handling in Python is asynchronous. https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers

See my previous comment: "CHECK_EVAL_BREAKER() matters for signals, but also multithreading (drop the GIL), asynchronous exception and pending calls."

If a thread executes a function which only uses opcodes which don't call CHECK_EVAL_BREAKER(), I understand that it can eat more than its slice of 5 ms, see sys.getswitchinterval():
https://docs.python.org/dev/library/sys.html#sys.getswitchinterval

So it's also a threads scheduling issue, no?

History
Date	User	Action	Args
2022-01-23 13:52:56	vstinner	set	recipients: + vstinner, gvanrossum, Mark.Shannon, eric.snow, corona10, kj
2022-01-23 13:52:56	vstinner	set	messageid: <1642945976.74.0.535147024255.issue46465@roundup.psfhosted.org>
2022-01-23 13:52:56	vstinner	link	issue46465 messages
2022-01-23 13:52:56	vstinner	create