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 grahamd
Recipients emptysquare, eric.snow, grahamd, ncoghlan, pitrou
Date 2015-07-03.11:12:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1435921945.94.0.98691274021.issue24554@psf.upfronthosting.co.za>
In-reply-to
Content
Right now mod_wsgi is the main user of sub interpreters. I wasn't even aware of this issue until Jesse found it. Thus in 7+ years, it never presented a problem in practice, possibly because in mod_wsgi sub interpreters are only ever destroyed on process shutdown and causing an issue at that point or a process crash was not noticed and tolerable

If however you are going to implement the "parallelism with sub-interpreters' idea you are making the possibility of encountering problems much more prevalent because you will likely have many more people using the feature, plus that a sub interpreter may be ephemeral and not necessarily kept around for the life of process, but destroyed at any time thus more readily pushing GC of objects into a different sub interpreter context if that is what can occur now.

It therefore seems to me that this would open up a huge can of worms if left to work as it does now with users seeing all sorts of unexpected behaviour if not very careful. Also, for GC of objects to be able to be done in a different interpreter context seems to suggest to me that the global GIL for whole process couldn't be eliminated in the first place. So at this I point can't see how you could move to a separate GIL for each interpreter context, if GC for each interpreter can't be separated easily or at all.
History
Date User Action Args
2015-07-03 11:12:25grahamdsetrecipients: + grahamd, ncoghlan, pitrou, eric.snow, emptysquare
2015-07-03 11:12:25grahamdsetmessageid: <1435921945.94.0.98691274021.issue24554@psf.upfronthosting.co.za>
2015-07-03 11:12:25grahamdlinkissue24554 messages
2015-07-03 11:12:25grahamdcreate