On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
Jeffrey Yasskin jyasskin at gmail.com writes:
Sorry, I didn't mean to get into a GIL debate. All I'm saying is that
I don't think changing the definition of Py_INCREF and Py_DECREF
justifies going to Python 4.0, so I
A couple thoughts:
I'm with the people who think the refcount should be accessed through
functions by apps that want ABI compatibility. In particular,
GIL-removal efforts are guaranteed to change how the refcount is
modified, but there's a good chance they wouldn't have to change the
API. (We
On Wed, May 20, 2009 at 10:14 AM, Antoine Pitrou solip...@pitrou.net wrote:
Jeffrey Yasskin jyasskin at gmail.com writes:
Over an 8-year lifetime for Python 3, Moore's law predicts that
desktop systems will have up to 64 cores, at which point even the
simplest GIL-removal strategy of making
Jeffrey Yasskin jyasskin at gmail.com writes:
Over an 8-year lifetime for Python 3, Moore's law predicts that
desktop systems will have up to 64 cores, at which point even the
simplest GIL-removal strategy of making refcounts atomic will be a
win, despite the 2x performance loss for a single
Jeffrey Yasskin jyasskin at gmail.com writes:
Sorry, I didn't mean to get into a GIL debate. All I'm saying is that
I don't think changing the definition of Py_INCREF and Py_DECREF
justifies going to Python 4.0, so I don't think their definitions
should be part of the ABI. If that's not what
Jeffrey Yasskin wrote:
Yes, that's my intention. (Well, not the annoying part, but making
them use Py_IncRef instead for ABI compatibility is, I think, a good
thing.) If they don't want ABI compatibility, they shouldn't ask for
it. Giving them something else useful to ask for is why I
Nick Jeffrey Yasskin wrote:
To decrease the annoyance of having to change source code, we could
have Py_INCREF(x) expand to Py_IncRef(x) in ABI-compatibility mode.
Nick Forcing developers to choose between the speed of the
Nick INCREF/DECREF macros and the proposed ABI
2009/5/20 s...@pobox.com:
I suspect it's not really germane to this discussion but if the
incref/decref functions were defined as inline would that effectively be
like using the macro versions vis a vis ABI compatibility?
The code would be inlined into applications defeating the point of
Benjamin Peterson writes:
2009/5/20 s...@pobox.com:
I suspect it's not really germane to this discussion but if the
incref/decref functions were defined as inline would that effectively be
like using the macro versions vis a vis ABI compatibility?
The code would be inlined into
On May 20, 2009, at 4:07 PM, Nick Coghlan wrote:
Forcing developers to choose between the speed of the INCREF/DECREF
macros and the proposed ABI compatibility mode for the benefit of an
as
yet hypothetical GIL-less CPython API implementation seems more like a
way to kill adoption of the ABI
2009/5/20 Stephen J. Turnbull step...@xemacs.org:
Benjamin Peterson writes:
2009/5/20 s...@pobox.com:
I suspect it's not really germane to this discussion but if the
incref/decref functions were defined as inline would that effectively be
like using the macro versions vis a vis
11 matches
Mail list logo
