2009/5/20 Stephen J. Turnbull :
> Benjamin Peterson writes:
> > 2009/5/20 :
> >
> > > 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?
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 co
Benjamin Peterson writes:
> 2009/5/20 :
>
> > 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 appl
2009/5/20 :
> 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
being able to c
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 AB
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 menti
On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou wrote:
> Jeffrey Yasskin 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 def
Jeffrey Yasskin 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 the A
On Wed, May 20, 2009 at 10:14 AM, Antoine Pitrou wrote:
> Jeffrey Yasskin 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
Jeffrey Yasskin 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 threa
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 have
11 matches
Mail list logo
