[issue7753] newgil backport

Changes by Julian Mehnle : -- nosy: +jmehnle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue7753] newgil backport

Jesús Cea Avión added the comment: Sorry for the nosy. There is something going wrong with my Firefox caching. -- ___ Python tracker ___ _

[issue7753] newgil backport

Changes by Jesús Cea Avión : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/pytho

[issue7753] newgil backport

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue7753] newgil backport

Changes by Todd Whiteman : -- nosy: +twhitema ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue7753] newgil backport

Changes by Eric Hopper : -- nosy: +Omnifarious ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue7753] newgil backport

Ross Cohen added the comment: On Fri, 29 Jan 2010 21:15:14 + Marc-Andre Lemburg wrote: > Breaking existing applications and ports of Python for 2.7 > certainly won't make anything easier for anyone. > > For 2.7 we will certainly not allow the above to happen, > since that's the version th

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Ross Cohen wrote: > > Ross Cohen added the comment: > > I am confused by this line of reasoning. Is it ok to ignore the > deprecation process in py3k but not in 2.x? Is it only ok if a core > developer does it? It's normally not ok to ignore the deprecat

[issue7753] newgil backport

Antoine Pitrou added the comment: > pthreads will default to use the real time clock. In order > to have them use the monotonic timer, you have to setup > a condition variable attribute: See the man-page for > pthread_condattr_setclock(). I'll look at that, but I'm not thrilled at the propect o

[issue7753] newgil backport

Ross Cohen added the comment: I am confused by this line of reasoning. Is it ok to ignore the deprecation process in py3k but not in 2.x? Is it only ok if a core developer does it? If the point of 2.7 is to make it easier for apps and packages to be ported to py3k, then what would be the point

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> It appears to be better to use clock_gettime(CLOCK_MONOTONIC) >> where available and only use gettimeofday() as fallback solution >> together with times(), ftime() and time(). > > Ok, I've

[issue7753] newgil backport

Antoine Pitrou added the comment: > It appears to be better to use clock_gettime(CLOCK_MONOTONIC) > where available and only use gettimeofday() as fallback solution > together with times(), ftime() and time(). Ok, I've tried and it's less good than expected. Using CLOCK_MONOTONIC absolutely kil

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Closing the issue since we can't backport to Python 2.7 due to the missing thread library support. The patch may still be useful for experiments by users, though, so thanks to Ross and Neil for creating it. -- resolution: -> rejected status: ope

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> The arguments given in that thread sound a bit strange to me: >> just because there were no changes to a few files, doesn't really >> say anything about whether they contain working code or

[issue7753] newgil backport

Antoine Pitrou added the comment: > The arguments given in that thread sound a bit strange to me: > just because there were no changes to a few files, doesn't really > say anything about whether they contain working code or not. That was a heuristic. Files which do not get any maintenance for y

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Le mercredi 27 janvier 2010 à 10:37 +, Marc-Andre Lemburg a écrit : >> >> I find it rather strange that Python 3.x now only supports >> NT and POSIX threads in ceval while it still suppor

[issue7753] newgil backport

Antoine Pitrou added the comment: Le mercredi 27 janvier 2010 à 10:33 +, Marc-Andre Lemburg a écrit : > > It appears to be better to use clock_gettime(CLOCK_MONOTONIC) > where available and only use gettimeofday() as fallback solution > together with times(), ftime() and time(). Thanks for

[issue7753] newgil backport

Antoine Pitrou added the comment: Le mercredi 27 janvier 2010 à 10:37 +, Marc-Andre Lemburg a écrit : > > I find it rather strange that Python 3.x now only supports > NT and POSIX threads in ceval while it still supports the > whole set of other thread implementations for the _thread > modu

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Ross Cohen wrote: >> By the way, the new GIL only works with POSIX and Windows NT threading APIs. >> Perhaps it can't be backported at all to 2.x, given that 2.x supports more >> threading APIs than py3k does? > > Looking at the Python/thread_*.h files, i

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Ross Cohen wrote: > > Ross Cohen added the comment: > > On Fri, 22 Jan 2010 09:32:36 + > Marc-Andre Lemburg wrote: > >> * Please add the fallback solutions from the time module in case >> gettimeofday() is not available. You cannot assume that "al

[issue7753] newgil backport

Ross Cohen added the comment: On Sat, 23 Jan 2010 18:23:10 + Antoine Pitrou wrote: > By the way, the new GIL only works with POSIX and Windows NT threading APIs. > Perhaps it can't be backported at all to 2.x, given that 2.x supports more > threading APIs than py3k does? Looking at the

[issue7753] newgil backport

Ross Cohen added the comment: On Fri, 22 Jan 2010 09:32:36 + Marc-Andre Lemburg wrote: > * Please add the fallback solutions from the time module in case > gettimeofday() is not available. You cannot assume that "all modern POSIX > systems" implement that API - it was introduced in POSI

[issue7753] newgil backport

Antoine Pitrou added the comment: I meant "worse than milliseconds", sorry. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue7753] newgil backport

Antoine Pitrou added the comment: As for your other comments, Marc-Andre: > * Please check whether you can move these variable declarations inside > the main loop function (as statics): > [snip] They are used in other functions than in the main loop, so it's not possible. > * Please add the f

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: >> Perhaps I'm missing some feature of the new GIL. Is there some >> documentation for it somewhere ? > > Almost nothing besides what is found in ceval_gil.h and in the following > thread: > http://mail.python.org/pipermail/python-dev/

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: On second thought, you're right: while sys.setcheckinterval() could be made to work with the switching interval, sys.getcheckinterval() could not be made to return anything useful. Still, please have a look at the other issues mentioned. They apply to new G

[issue7753] newgil backport

Antoine Pitrou added the comment: > Just use some conversion formula, e.g. switching interval in micro > seconds = constant * byte code check interval. We can then determine > a constant to match todays CPU performance. Well, there are two problems: - opcode execution cost varies so wildly that

[issue7753] newgil backport

Ross Cohen added the comment: Thanks Neil for fixing up the patch. As for Marc-Andre's comments, I'm happy to backport any further changes which happen on the py3k branch. I'd like to keep this as a strict backport, only changing things as necessary to get it to work with the older codebase. R

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> While the semantics are different, the result is similar and >> the actual numbers used are usually determined by experiment >> or rough estimate - noone expects the APIs to provide any kind

[issue7753] newgil backport

Antoine Pitrou added the comment: > While the semantics are different, the result is similar and > the actual numbers used are usually determined by experiment > or rough estimate - noone expects the APIs to provide any kind > of exact timing and it's not needed either. There's no reasonable fo

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> * Instead of deprecating the set/getcheckinterval APIs, convert the >> arguments passed to these to the switch interval. The new APIs >> set/getswitchinteral are then not needed. > > This

[issue7753] newgil backport

Changes by Kevin Watters : -- nosy: +kevinwatters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue7753] newgil backport

Neil Schemenauer added the comment: Here is an updated set of patches that includes the ceval_gil.h file as well as the documentation changes. -- Added file: http://bugs.python.org/file15974/gil-2.7.txt ___ Python tracker

[issue7753] newgil backport

Antoine Pitrou added the comment: > * Instead of deprecating the set/getcheckinterval APIs, convert the > arguments passed to these to the switch interval. The new APIs > set/getswitchinteral are then not needed. This is certainly not a good idea. The semantics are different, which is the rea

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: See Tools/pybench/systimes.py for more comments on clocks, ticks and update frequency. -- ___ Python tracker ___ __

[issue7753] newgil backport

Marc-Andre Lemburg added the comment: A few things: * The ceval_gil.h file is missing from the patch. * Please check whether you can move these variable declarations inside the main loop function (as statics): +/* This single variable consolidates all requests to break out of the fast path

[issue7753] newgil backport

Changes by Ralf Schmitt : -- nosy: +schmir ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue7753] newgil backport

Neil Schemenauer added the comment: Looks like the 2.7 patch has a spurious change to /Lib/unittest/runner.py. -- nosy: +nascheme ___ Python tracker ___ _

[issue7753] newgil backport

Changes by Brian Curtin : -- nosy: +brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue7753] newgil backport

Changes by Jesse Noller : -- nosy: +jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue7753] newgil backport

Changes by Brian Curtin : -- keywords: +needs review priority: -> high stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue7753] newgil backport

New submission from Ross Cohen : This is a backport of the newgil work to the 2.7 branch (otherwise known as trunk.) Patch is against r77678. Created by diffing r76193 (last in the newgil branch) against r76189 and applying the result. Generally applied cleanly and it looked as though only 1 r