[Python-ideas] Add hooks to asyncio lifecycle

[Nick Coghlan]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180610/6a6f2c2d/attachment-0001.html>