[Python-ideas] Add hooks to asyncio lifecycle

[Andrew Svetlov]

Policy locking is a viable idea at first glance.

On Sun, Jun 10, 2018 at 8:05 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 10 June 2018 at 07:59, Michel Desmoulin <desmoulinmichel at gmail.com>
> wrote:
>
>> What I'm proposing is to make that easy to implement by just letting
>> anyone put a check in there.
>>
>> Overriding policy, loops or tasks factories are usually down for
>> critical parts of the system. The errors emerging from a bug in there
>> are very cryptic.
>>
>> Asyncio design made the choice to expose very low level things. You
>> literally don't have this problem in languages like JS because nobody
>> can change those.
>>
>> Now it's here, it's a footgun, and it would be nice to provide a way to
>> put it in a holster.
>>
>
> With the API need framed that way, perhaps all that asyncio is currently
> missing is an "asyncio.lock_policy(unlock_token, err_callback)" API such
> that your application can declare that initialisation is completed and no
> further event loop policy changes should be allowed?
>
> (The "unlock_token" would be an arbitrary app-provided object that must
> also be passed to the corresponding "unlock_policy" call - that way
> libraries couldn't unlock the policy after the application locks it, since
> they won't have a reference to the app-specific unlock token).
>
> Adding further callback hooks for more events seems like it will just push
> the problem back another level, and you'll have the potential for conflicts
> between callbacks registered with the new hooks, and an even harder to
> understand overall system.
>
> By contrast, the above would be amenable to doing something like:
>
>     1. Per-process setup code establishes a particular event loop policy,
> and then locks it
>     2. Until the policy gets unlocked again, attempts to change it will
> call the err_callback (so the app can raise a custom access denied
> exception)
>     3. get_event_loop(), set_event_loop(), and new_event_loop() are all
> already managed by the event loop policy, so shouldn't need new hooks
>     4. stop(), close(), set_debug(), set_task_factory(), etc are all
> already managed by the event loop (and hence by the event loop policy), so
> shouldn't need new hooks
>
> Right now, the weak link in that chain is that there's no way for the
> application to keep a library from switching out the event policy with a
> new one, and subsequently bypassing all of the app's control over how it
> expects event loops to be managed. Given a way to close that loophole, the
> application should already have the ability to enforce everything else that
> it wants to enforce via the existing event loop and event loop policy APIs.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180610/682ef8c6/attachment.html>