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

[STINNER Victor]

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 holding the GIL, Python thread not holding the GIL.

I found why test_read_all_from_pipe_reader() is running with more than one thread.

I reproduced the issue on my FreeBSD VM. run_test_server() and run_test_unix_server() functions of test_utils create Python threads, these functions are used in the test_asyncio.

The problem is that the PyThreadState_DeleteCurrent() function (called from t_bootstrap() of _threadmodule.c) may yield the CPU to another thread. Other Python threads are running when the line "MUTEX_UNLOCK(gil_mutex);" is executed in the drop_gil() function, before drop_gil() exits.

t_bootstrap() -> PyThreadState_DeleteCurrent() -> PyEval_ReleaseLock() -> drop_gil(NULL)

It means that Python threads are not deleted immediatly, but may be deleted "later".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21645>
_______________________________________