Author pitrou
Recipients DazWorrall, aconrad, alex, andrix, brian.curtin, carljm, coderanger, cool-RR, dabeaz, djc, durin42, eric.araujo, eric.smith, flox, gregory.p.smith, jcea, jhylton, karld, kevinwatters, konryd, larry, loewis, mahmoudimus, movement, neologix, nirai, pitrou, rcohen, rh0dium, salgado, tarek, thouis, ysj.ray
Date 2010-04-26.09:36:26
SpamBayes Score 1.17795e-13
Marked as misclassified No
Message-id <1272274719.3539.4.camel@localhost>
In-reply-to <1272255210.74.0.106498514844.issue7946@psf.upfronthosting.co.za>
Content
Dave,

> In the current implementation, threads perform a timed-wait on a
> condition variable.  If time expires and no thread switches have
> occurred, the currently running thread is forced to drop the GIL.

A problem, as far as I can see, is that these timeout sleeps run
periodically, regardless of the actual times at which thread switching
takes place. I'm not sure it's really an issue but it's a bit of a
departure from the "ideal" behaviour of the switching interval.

> A new attribute 'cpu_bound' is added to the PyThreadState structure.
> If a thread is ever forced to drop the GIL, this attribute is simply
> set True (1).  If a thread gives up the GIL voluntarily, it is set
> back to False (0).  This attribute is used to set up simple scheduling
> (described next).

Ok, so it's not very different, at least in principle, from what
gilinter.patch does, right?
(and actually, the benchmark results look very similar)
History
Date User Action Args
2010-04-26 09:36:28pitrousetrecipients: + pitrou, loewis, jhylton, gregory.p.smith, jcea, movement, larry, eric.smith, kevinwatters, tarek, djc, karld, carljm, coderanger, durin42, eric.araujo, nirai, alex, andrix, konryd, brian.curtin, flox, DazWorrall, salgado, cool-RR, rh0dium, rcohen, dabeaz, mahmoudimus, aconrad, ysj.ray, neologix, thouis
2010-04-26 09:36:26pitroulinkissue7946 messages
2010-04-26 09:36:26pitroucreate