Author nirai
Recipients DazWorrall, aconrad, alex, andrix, brian.curtin, carljm, coderanger, cool-RR, dabeaz, djc, donaldjeo, durin42, eric.araujo, eric.smith, flox, gregory.p.smith, jcea, jhylton, karld, kevinwatters, konryd, larry, loewis, mahmoudimus, movement, neologix, nirai, pitrou, rcohen, rh0dium, tarek, thouis, ysj.ray
Date 2010-04-30.08:24:02
SpamBayes Score 0.215023
Marked as misclassified No
Message-id <1272615845.67.0.502026603127.issue7946@psf.upfronthosting.co.za>
In-reply-to
Content
Dave, 

The behavior of your patch on Windows XP/2003 (and earlier) might be related to the way Windows boosts thread priority when it is signaled. 

Try to increase priority of monitor thread and slice size. Another thing to look at is how to prevent Python CPU bound threads from (starving) messing up scheduling of threads of other processes. Maybe increasing slice significantly can help in this too (50ms++ ?).

XP/NT/CE scheduling and thread boosting affect all patches and the current GIL undesirably (in different ways). Maybe it is possible to make your patch work nicely on these systems:
http://www.sriramkrishnan.com/blog/2006/08/tale-of-two-schedulers-win_115489794858863433.html

Vista and Windows 7 involve CPU cycle counting which results in more sensible scheduling:
http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx
History
Date User Action Args
2010-04-30 08:24:07niraisetrecipients: + nirai, loewis, jhylton, gregory.p.smith, jcea, pitrou, movement, larry, eric.smith, kevinwatters, tarek, djc, karld, carljm, coderanger, durin42, eric.araujo, alex, andrix, konryd, brian.curtin, flox, DazWorrall, cool-RR, rh0dium, rcohen, dabeaz, mahmoudimus, aconrad, ysj.ray, neologix, thouis, donaldjeo
2010-04-30 08:24:05niraisetmessageid: <1272615845.67.0.502026603127.issue7946@psf.upfronthosting.co.za>
2010-04-30 08:24:03nirailinkissue7946 messages
2010-04-30 08:24:02niraicreate