Nick Coghlan added the comment:
While I agree with Raymond regarding the performance implications if this isn't
handled carefully, I think we're also getting to a point where better
accounting for signal handling latency in inner loops is something that could
be considered for 3.7 - the benchmarking infrastructure being built out to
measure performance optimisations would also allow overhead tuning of a
"batched iteration" idiom where signals were checked for either every N
thousand iterations, periodically based on time, or some combination of the two.
Benchmarking to measure the speed impact is going to be essential, though -
this is a case where changing the behaviour is clearly possible, so the key
questions are whether or not the resulting runtime overhead can be made low
enough to be deemed acceptable, and whether or not it can be done in a way that
doesn't make the affected parts of the code base effectively unreadable.
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list