2016-12-31 16:42 GMT+09:00 Nick Coghlan :
> On 31 December 2016 at 08:24, Masayuki YAMAMOTO > wrote:
>
>> I have read the discussion and I'm sure that use structure as Py_tss_t
>> instead of platform-specific data type. Just as Steve said that Py_tss_t
>> should be genuinely treated as an opaque
On 31 December 2016 at 08:24, Masayuki YAMAMOTO
wrote:
> I have read the discussion and I'm sure that use structure as Py_tss_t
> instead of platform-specific data type. Just as Steve said that Py_tss_t
> should be genuinely treated as an opaque type, the key state checking
> should provide macro
I have read the discussion and I'm sure that use structure as Py_tss_t
instead of platform-specific data type. Just as Steve said that Py_tss_t
should be genuinely treated as an opaque type, the key state checking
should provide macros or inline functions with name like
PyThread_tss_is_created. Wel
On Fri, Dec 30, 2016 at 5:05 PM, Nick Coghlan wrote:
> On 29 December 2016 at 22:12, Erik Bray wrote:
>>
>> 1) CPython's TLS: Defines -1 as an uninitialized key (by fact of the
>> implementation--that the keys are integers starting from zero)
>> 2) pthreads: Does not definite an uninitialized def
On 29 December 2016 at 22:12, Erik Bray wrote:
> 1) CPython's TLS: Defines -1 as an uninitialized key (by fact of the
> implementation--that the keys are integers starting from zero)
> 2) pthreads: Does not definite an uninitialized default value for
> keys, for reasons described at [1] under "No
On Wed, Dec 21, 2016 at 5:07 PM, Nick Coghlan wrote:
> On 21 December 2016 at 20:01, Erik Bray wrote:
>>
>> On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan wrote:
>> > Option 2: Similar to option 1, but using a custom type alias, rather
>> > than
>> > using a C99 bool directly
>> >
>> > The closes
Top-posted from my Windows Phone
-Original Message-
From: "Masayuki YAMAMOTO"
Sent: 12/23/2016 16:34
To: "Erik Bray"
Cc: "python-ideas@python.org"
Subject: Re: [Python-ideas] New PyThread_tss_ C-API for CPython
2016-12-21 19:01 GMT+09:00 Erik Bray :
On We
2016-12-21 19:01 GMT+09:00 Erik Bray :
> On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan wrote:
> > Ouch, I'd missed that, and I agree it's not a negligible implementation
> > detail - there are definitely applications embedding CPython out there
> that
> > rely on being able to run multiple Initia
On 21 December 2016 at 20:01, Erik Bray wrote:
> On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan wrote:
> > Option 2: Similar to option 1, but using a custom type alias, rather than
> > using a C99 bool directly
> >
> > The closest API we have to these semantics at the moment would be
> > PyGILSta
On Wed, Dec 21, 2016 at 11:01 AM, Erik Bray wrote:
> That all sounds good--between the two option 2 looks a bit more explicit.
>
> Though what about this? Rather than adding another type, the original
> proposal could be changed slightly so that Py_tss_t *is* partially
> defined as a struct consi
On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan wrote:
> On 21 December 2016 at 01:35, Masayuki YAMAMOTO
> wrote:
>>
>> 2016-12-20 22:30 GMT+09:00 Erik Bray :
>>>
>>> This is probably an implementation detail, but ISTM that even with
>>> PyThread_call_once, it will be necessary to reset any used on
On 21 December 2016 at 01:35, Masayuki YAMAMOTO
wrote:
> 2016-12-20 22:30 GMT+09:00 Erik Bray :
>
>> This is probably an implementation detail, but ISTM that even with
>> PyThread_call_once, it will be necessary to reset any used once_flags
>> manually in PyOS_AfterFork, essentially for the same
2016-12-20 22:30 GMT+09:00 Erik Bray :
> This is probably an implementation detail, but ISTM that even with
> PyThread_call_once, it will be necessary to reset any used once_flags
> manually in PyOS_AfterFork, essentially for the same reason the
> autoTLSkey is reset there currently...
>
Deleting
On Tue, Dec 20, 2016 at 9:26 AM, Nick Coghlan wrote:
> On 20 December 2016 at 00:53, Erik Bray wrote:
>>
>> On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray wrote:
>> >> Likewise - we know the status quo isn't right, and the proposed change
>> >> addresses that. In reviewing the patch on the tracker,
On 20 December 2016 at 00:53, Erik Bray wrote:
> On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray wrote:
> >> Likewise - we know the status quo isn't right, and the proposed change
> >> addresses that. In reviewing the patch on the tracker, the one downside
> I've
> >> found is that due to "pthread_ke
On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray wrote:
> On Mon, Dec 19, 2016 at 1:11 PM, Nick Coghlan wrote:
>> On 17 December 2016 at 03:51, Antoine Pitrou wrote:
>>>
>>> On Fri, 16 Dec 2016 13:07:46 +0100
>>> Erik Bray wrote:
>>> > Greetings all,
>>> >
>>> > I wanted to bring attention to an issu
On Mon, Dec 19, 2016 at 1:11 PM, Nick Coghlan wrote:
> On 17 December 2016 at 03:51, Antoine Pitrou wrote:
>>
>> On Fri, 16 Dec 2016 13:07:46 +0100
>> Erik Bray wrote:
>> > Greetings all,
>> >
>> > I wanted to bring attention to an issue that's been languishing on the
>> > bug tracker since last
On 17 December 2016 at 03:51, Antoine Pitrou wrote:
> On Fri, 16 Dec 2016 13:07:46 +0100
> Erik Bray wrote:
> > Greetings all,
> >
> > I wanted to bring attention to an issue that's been languishing on the
> > bug tracker since last year, which I think would best be addressed by
> > changes to C
On Sat, Dec 17, 2016 at 8:21 AM, Stephen J. Turnbull
wrote:
> Erik Bray writes:
>
> > Abstract
> >
> >
> > The proposal is to add a new Thread Local Storage (TLS) API to CPython
> > which would supersede use of the existing TLS API within the CPython
> > interpreter, while deprecati
On Sun, Dec 18, 2016 at 12:10 AM, Masayuki YAMAMOTO
wrote:
> 2016-12-17 18:35 GMT+09:00 Stephen J. Turnbull
> :
>>
>> I don't understand this. I assume that there are no such platforms
>> supported at present. I would think that when such a platform becomes
>> supported, code supporting "key" fu
2016-12-17 18:35 GMT+09:00 Stephen J. Turnbull :
> I don't understand this. I assume that there are no such platforms
> supported at present. I would think that when such a platform becomes
> supported, code supporting "key" functions becomes unsupportable
> without #ifdefs on that platform, at
Erik Bray writes:
> Abstract
>
>
> The proposal is to add a new Thread Local Storage (TLS) API to CPython
> which would supersede use of the existing TLS API within the CPython
> interpreter, while deprecating the existing API.
Thank you for the analysis.
> Further, the old PyTh
Erik Bray writes:
> Abstract
>
>
> The proposal is to add a new Thread Local Storage (TLS) API to CPython
> which would supersede use of the existing TLS API within the CPython
> interpreter, while deprecating the existing API.
Thank you for the analysis!
Question:
> Further, t
Hi, I'm patch author,
I don't need to say anything for Erik's draft. I feel awesome that it has
been clearly to explain, especially for history of API and against PEP.
Thanks for great job, Erik!
Cheers,
Masayuki
___
Python-ideas mailing list
Python-ide
On Fri, Dec 16, 2016 at 11:07 PM, Erik Bray wrote:
> I haven't written this up in the proper PEP format because I want to
> see if the idea has some broader support first, and it's also not
> clear to me whether C-API changes (especially to undocumented APIs)
> even require their own PEP.
>
You'r
On Fri, 16 Dec 2016 13:07:46 +0100
Erik Bray wrote:
> Greetings all,
>
> I wanted to bring attention to an issue that's been languishing on the
> bug tracker since last year, which I think would best be addressed by
> changes to CPython's C-API. The original issue is at
> http://bugs.python.org/
On Fri, Dec 16, 2016 at 6:07 AM, Erik Bray wrote:
> Greetings all,
>
> I wanted to bring attention to an issue that's been languishing on the
> bug tracker since last year, which I think would best be addressed by
> changes to CPython's C-API. The original issue is at
> http://bugs.python.org/iss
Greetings all,
I wanted to bring attention to an issue that's been languishing on the
bug tracker since last year, which I think would best be addressed by
changes to CPython's C-API. The original issue is at
http://bugs.python.org/issue25658, but I have made an effort below in
a sort of proto-PE
28 matches
Mail list logo
