Message 104203 - Python tracker

➜

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	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.1779466e-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)

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:28	pitrou	set	recipients: + 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:26	pitrou	link	issue7946 messages
2010年04月26日 09:36:26	pitrou	create

homepage