Yury Selivanov <[email protected]> added the comment:
> As to exposing Py_AddPendingCall() as sys.addpendingcall, that might be
> opening a can of worms. Injecting code into the eval loop at some arbitrary
> ("soon") future time requires care and the code isn't well exercised
> historically (much like subinterpreters).
Well, it's absolutely the same mechanism that signal handlers use. It looks
like this can of works has been open for a pretty long time now :)
The whole point of adding this API is to make it possible for asyncio to work
with the "signals" module not from the main thread. I expect 99.9% of other
use cases to be either about signals or other super low-level stuff that needs
the main thread (off the top of my head I can't name any :))
> It also adds burden on other Python implementations.
Python signal processing *requires* users callbacks to be executed in the main
thread (whereas Unix can deliver the signal to any thread, potentially).
Therefore I think that any alternative Python implementation should have a
mechanism to schedule code execution in the main thread.
> My point is, let's think this through before adding sys.addpendingcall(). :)
> Is there another way this could be done that doesn't open a can of worms?
Maybe. One of such ways is to enable signal.signal calls from non-main threads.
But I'm not sure this is possible for all platforms we support. Maybe Victor
or Andrew can shed more light on this.
> Also, at the very least it should probably be a "private" function (i.e
> sys._addpendingcall).
Maybe. The problem is that asyncio must work the same on PyPy, which means
that the sys API it uses should be available on PyPy too. In which case, they
will kind of have to add it, which means that there's no point in making it
semi-private. OTOH, I wouldn't mind sys._addpendingcall(), as long as PyPy
implements it.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue37088>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
