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 asvetlov
Recipients asvetlov, gvanrossum, vstinner, yselivanov
Date 2015-09-15.15:53:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1442332430.62.0.115291557579.issue25074@psf.upfronthosting.co.za>
In-reply-to
Content
> You should try to implement something in aiohttp or even in the application to cleanup objects at exit. For example, it's probably wrong if you still have tasks when the event loop is closed. Especially if tasks are still pending.

The problem is for client API. For server I have more control and  implemented checks like you suggest.

For for client lazy user writes floppy code like:

    client = aiohttp.ClientSession()
    resp = yield from client.get(url)
    text = yield from resp.text()

Client is closed by GC, at the moment is not determined is loop has been closed or not (GC releases object in non-determenistic way).

So without changes I just cannot use `loop.call_exception_handler()` in `__del__` methods.

It's not only aiohttp issue but we should get rid of `call_exception_handler()` reports in asyncio itself for the same reason. 

We have `logger` and `warnings` modules usage e.g. in asyncio transports, it's not safe if transport is not closed properly before interpreter shutdown.

`subprecess` module has tricks for proper destruction like I've used in my patch.
History
Date User Action Args
2015-09-15 15:53:50asvetlovsetrecipients: + asvetlov, gvanrossum, vstinner, yselivanov
2015-09-15 15:53:50asvetlovsetmessageid: <1442332430.62.0.115291557579.issue25074@psf.upfronthosting.co.za>
2015-09-15 15:53:50asvetlovlinkissue25074 messages
2015-09-15 15:53:50asvetlovcreate