STINNER Victor <vstin...@python.org> added the comment:
> I think this is a good idea. MultiLoopChildWatcher could use setwakeupfd with 
> some no-op callback just to wakeup the loop.

A no-op doesn't solve the issue. It doesn't wake up the event loop. There are 
only two options to wake up the event loop:

* Raise an exception in the Python signal handler
* Generate any event which stops the event loop polling. In practice, it means 
to write into the event loop self pipe.

This issue is similar to call_soon() which doesn't wake up the event loop if 
called from a different thread: you must call call_soon_threadsafe() which... 
writes into the self pipe. The self pipe again!

--

MultiLoopChildWatcher cannot use setwakeupfd if it's also used by an event loop 
to register a signal handler (like CTRL+C). Python currently supports a single 
signal wakeup FD.

The event loop *must* set the wakeup FD to its own self pipe. Otherwise, the 
asynchronous Python signal handler register by add_signal_handler() is not 
called. Extract of the Unix add_signal_handler():

            # Register a dummy signal handler to ask Python to write the signal
            # number in the wakeup file descriptor. _process_self_data() will
            # read signal numbers from this file descriptor to handle signals.
            signal.signal(sig, _sighandler_noop)

Currently, MultiLoopChildWatcher is not related to any event loop, it cannot 
access such "self pipe".

If MultiLoopChildWatcher is modified to be attached to an event loop... does it 
contract the whole purpose of MultiLoopChildWatcher?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to