On 2012-10-30, at 1:53 AM, Greg Ewing
Yury Selivanov wrote:
So in your example scheduler would never ever has a question of interrupting c2(), because it wasn't called with any restriction/timeout. There simply no reason to interrupt it ever.
But there's nothing to stop someone writing
def c3(): try: yield from with_timeout(10.0, c1()) except TimeoutError: print("That's cool, I can cope with that")
Also, it's not just TimeoutErrors that are a potential problem, it's any asynchronous exception. For example, the task calling c1() might get cancelled by another task while c2() is blocked. If cancelling is implemented by throwing in an exception, you have the same problem.
Then you need scheduler to know if it is in its finally or not. Because its c2() which was run with a timeout. It's c2() code that may be subject to aborting.
I'm really not following your reasoning here. You seem to be speaking as if with_timeout() calls only have an effect one level deep. But that's not the case -- the frame that a TimeoutError gets thrown into by with_timeout() can be nested any number of yield-from calls deep.
Greg, Looks like I'm failing to explain my point of view (which is maybe wrong). The problem is tough, and without a shared code to debug and test ideas on it's just hard to communicate. Let's get back to this issue once we have a framework/library to work on. Thanks, Yury