[issue21645] asyncio: Race condition in signal handling on FreeBSD

Roundup Robot added the comment: New changeset fe456770b454 by Yury Selivanov in branch 'default': asyncio: Reverting 69d474dab479 as issue #21645 is now closed and debug is no longer needed https://hg.python.org/cpython/rev/fe456770b454 -- ___ Pytho

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: The test suite passed on FreeBSD 9 buildbot (3.4, 3.5 and my custom builds). I consider that the bug is now fixed. -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: I commited the patch into Tulip (c149370c8027), Python 3.4 (c4f053f1b47f), Python 3.5 (2176496951a4). I'm now waiting for the buildbot. -- ___ Python tracker

[issue21645] asyncio: Race condition in signal handling on FreeBSD

Roundup Robot added the comment: New changeset c4f053f1b47f by Victor Stinner in branch '3.4': Python issue #21645, Tulip issue 192: Rewrite signal handling http://hg.python.org/cpython/rev/c4f053f1b47f New changeset 2176496951a4 by Victor Stinner in branch 'default': (Merge 3.4) Python issue #2

[issue21645] asyncio: Race condition in signal handling on FreeBSD

Guido van Rossum added the comment: The more esoteric system calls you use the more you end up debugging it on esoteric platforms. :-( On Thu, Jul 17, 2014 at 9:17 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > > I don't know if it can be useful, but there is also the > si

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: > I don't know if it can be useful, but there is also the > signal.pthread_sigmask() which can be used to "queue" pending signals. (...) Oh, I didn't remember that I opened the issue #12060 to discuss "real time signals". The summary is that the wakeup fd shou

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: > The intention if the code was that the Py_AddPendingCall() would complete > before the thread switch. In fact I also expected Py_AddPendingCall() to be called *before* writing the signal number into the "wakeup fd". I guess that before nobody was relying on

[issue21645] asyncio: Race condition in signal handling on FreeBSD

Guido van Rossum added the comment: I did my meditation. I now understand the race: - main thread is blocked in select() (or poll() etc.) - C-level signal handler is called in thread B and writes a byte to self-pipe - kernel immediately switches threads - main thread wakes up, reads data from se

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: IMO we must handle signals correctly when there are more than one thread. On Linux, it looks like the C signal handler is always called from the main thread. On FreeBSD, it looks like the C signal handler can be called in any thread, C thread, Python thread ho

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: I ran test_asyncio on my own FreeBSD VM, with the sandbox/issue21645 repository and I got a new (different) error on signal handling: RuntimeError('reentrant call inside') when writing into sys.stderr. To be fair: this bug was introduced by my changes in this

[issue21645] asyncio: Race condition in signal handling on FreeBSD

STINNER Victor added the comment: "A solution would be to schedule the callback in the event loop. Since Python 3.3, the C signal handler writes the signal number, which should be enough to find and schedule the Python callback." I wrote a patch implementing this idea to fix the issue: https:/

[issue21645] asyncio: Race condition in signal handling on FreeBSD

Changes by STINNER Victor : -- title: Race condition in signal handling on FreeBSD -> asyncio: Race condition in signal handling on FreeBSD ___ Python tracker ___ __