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 <>

> 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)
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