Message200518
| Author |
neologix |
| Recipients |
David.Edelsohn, gvanrossum, larry, neologix, pitrou, python-dev, skrah |
| Date |
2013年10月19日.23:34:07 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAH_1eM0DJvj7PS0j85VD6GU0WT-dY+gC5rHoBB7E5-TP1LOWJA@mail.gmail.com> |
| In-reply-to |
<CAP7+vJLatN-SG4LjEsLDdqA5ievvxYvV9q-uVPY=+qy6NLRR1g@mail.gmail.com> |
| Content |
> Guido van Rossum added the comment:
>
> Actually, I think we're talking about the actual select() syscal not
> returning when SIGCHLD is received and handled. Running the C-level handler
> isn't enough, the syscall must return with EINTR so the Python handler can
> run (which then writes a byte to the self-pipe to ensure select() returns,
> but that seems too late).
I just realized the following: there's no need for EINTR to break out
of select(), that's what the self-pipe is for: since the write-end is
registered as wakeup FD, and the read-end is registered in the
selector, when the C-level signal handler is executed, it writes to
the wakeup FD, therefore the select() syscall should return with the
read-end ready, or more likely fail with EINTR. And then, the
Python-level signal handler should be executed (from the main loop),
scheduling a callback, and re-trigerring a wakup through the
self-pipe.
If this doesn't work as-is, I only see two explanations:
- the C-level signal handler doesn't get called, which seems impossible
- the python-level signal handler doesn't get executed before the main
loop re-enters select(), but since the new GIL signal handlers are
called at each eval loop
In short, I'm puzzled. I can tell why my patch should work, but I'm
not sure why the current approach doesn't. |
|