homepage

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 dabeaz
Recipients DazWorrall, alex, brian.curtin, carljm, coderanger, dabeaz, eric.smith, flox, jhylton, karld, kevinwatters, loewis, mahmoudimus, nirai, pitrou, rcohen, rh0dium, tarek
Date 2010年03月16日.02:36:33
SpamBayes Score 1.9308216e-10
Marked as misclassified No
Message-id <1268706995.07.0.920646847998.issue7946@psf.upfronthosting.co.za>
In-reply-to
Content
You know, I almost wonder whether this whole issue could be fixed by just adding a user-callable function to optionally set a thread priority number. For example:
 sys.setpriority(n)
Modify the new GIL code so that it checks the priority of the currently running thread against the priority of the thread that wants the GIL. If the running thread has lower priority, it immediately drops the GIL. 
Other than having this added preemption, do nothing else---just throw it all back to the user to come up with the proper "priorities." 
If there was something like this, it would completely fix the overlapped compute and I/O problem I mentioned. I'd just set a higher priority on the background I/O threads and be done with it. Problem solved.
Ok, it's only a thought.
History
Date User Action Args
2010年03月16日 02:36:35dabeazsetrecipients: + dabeaz, loewis, jhylton, pitrou, eric.smith, kevinwatters, tarek, karld, carljm, coderanger, nirai, alex, brian.curtin, flox, DazWorrall, rh0dium, rcohen, mahmoudimus
2010年03月16日 02:36:35dabeazsetmessageid: <1268706995.07.0.920646847998.issue7946@psf.upfronthosting.co.za>
2010年03月16日 02:36:33dabeazlinkissue7946 messages
2010年03月16日 02:36:33dabeazcreate

AltStyle によって変換されたページ (->オリジナル) /