This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients giampaolo.rodola, gvanrossum, pitrou, python-dev, vstinner, yselivanov
Date 2014-07-17.09:26:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1405589214.86.0.305357484165.issue21645@psf.upfronthosting.co.za>
In-reply-to
Content
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".
History
Date User Action Args
2014-07-17 09:26:54vstinnersetrecipients: + vstinner, gvanrossum, pitrou, giampaolo.rodola, python-dev, yselivanov
2014-07-17 09:26:54vstinnersetmessageid: <1405589214.86.0.305357484165.issue21645@psf.upfronthosting.co.za>
2014-07-17 09:26:54vstinnerlinkissue21645 messages
2014-07-17 09:26:54vstinnercreate