carrier local

[Dmitry Zaslavsky]

That would work 
Thanks 

Sent from my iPhone

> On Apr 4, 2020, at 5:48 AM, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
> 
> 
> It is no longer the same pattern as ThreadLocal, so not really get(). It is more like borrow and return, try-with-resource like.
> 
> Alex
> 
>> On Fri, 3 Apr 2020, 21:43 Dmitry Zaslavsky, <dmitry.zaslavsky at gmail.com> wrote:
>> I don’t think we totally disagree. I just hope there is way to achieve the performance requirements :)
>> 
>> I very much like the idea if I understood you correctly:, 
>> >>   Just platform-defined O(1) state changes, like acquire and release…
>> CTL.get  (will remove as well) 
>> CTL.put (to return
>> 
>> if get and put are basically extra nulling out the value and setting it back in. I think it would be great
>> There is room to make that faster than exiting TL (which are relatively slow)
>> 
>> 
>> 
>> > On Apr 3, 2020, at 3:45 PM, John Rose <john.r.rose at oracle.com> wrote:
>> > 
>> > My advice:  Think in terms of O(1) guaranteed non-blocking operations
>> > which a CTL can offer to “check out” and “check in” resources that are
>> > tied to a CT.  I think that’s the best you can get.  No general lambdas,
>> > and no other “hook” (like an interface or factory) for user code to gum
>> > up the scheduler.  Just platform-defined O(1) state changes, like acquire
>> > + release, or atomic increment.
>>