[Python-ideas] Add hooks to asyncio lifecycle
andrew.svetlov at gmail.com
Sun Jun 10 03:02:25 EDT 2018
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>
>> 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
> 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.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas