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 nirai
Recipients DazWorrall, alex, brian.curtin, carljm, coderanger, dabeaz, eric.smith, flox, jcea, jhylton, karld, kevinwatters, loewis, mahmoudimus, nirai, pitrou, rcohen, rh0dium, tarek
Date 2010-03-25.16:03:52
SpamBayes Score 2.6244245e-06
Marked as misclassified No
Message-id <1269533033.73.0.657183118612.issue7946@psf.upfronthosting.co.za>
In-reply-to
Content
> It's a dual-core Linux x86-64 system. But, looking at the patch again, the reason is obvious:
>
> #define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate
> >tick_counter % 1000 == 0))
>
> `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, which based its speculative operation on the number of elapsed opcodes (and which also gave bad latency numbers on the regex workload).

The flag_check_depleted is there to work around this problem. It is raised by waiters which timeout.

What distribution and version of GNU/Linux are you using?

As for the CLOCK_THREAD_CPUTIME_ID clock, support was added to FreeBSD recently in version 7.1, which I guess is not good enough:
http://www.freebsd.org/releases/7.1R/relnotes.html

I did not find yet anything on Solaris. Do you know of an alternative way to measure thread running time on Posix?
History
Date User Action Args
2010-03-25 16:03:54niraisetrecipients: + nirai, loewis, jhylton, jcea, pitrou, eric.smith, kevinwatters, tarek, karld, carljm, coderanger, alex, brian.curtin, flox, DazWorrall, rh0dium, rcohen, dabeaz, mahmoudimus
2010-03-25 16:03:53niraisetmessageid: <1269533033.73.0.657183118612.issue7946@psf.upfronthosting.co.za>
2010-03-25 16:03:52nirailinkissue7946 messages
2010-03-25 16:03:52niraicreate