Hi,

The main message is "Task was destroyed but it is pending!", but you
should see the status of the task in the lines below: "<Task
cancelling ...>", no?

I agree that we can improve the main message.

It's not obvious that cancelling a task is asynchronous. In fact, the
cancellation can be ignored by the coroutine...

Victor

2014-08-06 10:35 GMT+02:00 Martin Richard <[email protected]>:
> In fact, the documentation is quite clear about Task.cancel() being
> different than Future.cancel(). Logging a different message could highlight
> the fact that canceling a task does not change its state change.
>
> Anyway, now I know that it's considered a bad practice not to let a task the
> chance to terminate properly.
>
> Cheers,
> Martin
>
>
> On Tuesday, August 5, 2014 7:33:55 PM UTC+2, Guido van Rossum wrote:
>>
>> You're not giving the task a chance to handle the cancel() (which it may
>> want to do using try/except). So I think technically it is correct that you
>> are seeing this warning in the logs. Maybe we could make it clearer by
>> logging a different message when _must_cancel is set?
>>
>>
>> On Tue, Aug 5, 2014 at 4:27 AM, Martin Richard <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> When cancelling a task outside of the loop, the task is still considered
>>> pending because the result (CancelledError) will only be set when the loop
>>> will try to run the task once more.
>>>
>>> In the current version of tulip (last revision from 30 July), a
>>> consequence of this is that the message "Task was destroyed but it is
>>> pending!" can be logged, which is not exactly true.
>>>
>>> I wrote a test case:
>>>
>>> import asyncio
>>>
>>> l = asyncio.get_event_loop()
>>>
>>> def raise_base_exception():
>>>     raise SystemExit()
>>>
>>> @asyncio.coroutine
>>> def coro():
>>>     l.call_soon(raise_base_exception)
>>>     yield from asyncio.sleep(10)
>>>
>>> task = asyncio.async(coro())
>>>
>>> try:
>>>     l.run_forever()
>>> except BaseException:
>>>     task.cancel()
>>>
>>> I'm not sure if the behavior can be considered as a bug in tulip or if
>>> it's because I rely on a bad design, but in this case I'm sure that when I
>>> except a BaseException, I don't want to run the loop anymore.
>>>
>>> A simple fix for this in tulip would be to set self._log_destroy_pending
>>> to False when calling cancel().
>>>
>>> Cheers,
>>> Martin
>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)

Reply via email to