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 ncoghlan
Recipients eric.snow, nanjekyejoannah, ncoghlan, pablogsal, pconnell, pitrou, tim.peters, vstinner
Date 2019-12-31.06:30:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1577773846.41.0.113509162941.issue36476@roundup.psfhosted.org>
In-reply-to
Content
Thinking about that idea further, I don't think that change would help much, since the relevant operations should already be checking for thread termination when they attempt to reacquire the GIL.

That means what we're missing is:

1. When daemon threads still exist after the non-daemon threads terminate, deliberately giving them additional time to run (and hence terminate)
2. Explicitly attempting to kick daemon threads out of blocking system calls by sending them signals to provoke EINTR (I have no idea if there's a windows equivalent for this, but we should be able to use pthread_kill on POSIX systems. However, choosing *which* wakeup signal to send could be fraught with compatibility problems)
History
Date User Action Args
2019-12-31 06:30:46ncoghlansetrecipients: + ncoghlan, tim.peters, pitrou, vstinner, eric.snow, pconnell, pablogsal, nanjekyejoannah
2019-12-31 06:30:46ncoghlansetmessageid: <1577773846.41.0.113509162941.issue36476@roundup.psfhosted.org>
2019-12-31 06:30:46ncoghlanlinkissue36476 messages
2019-12-31 06:30:46ncoghlancreate