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.