taming resource scopes

[Samuel Audet]

Hi, Maurizio,

Thanks for taking the time to write this down! It's all very interesting 
to have a sense of how various resources could be managed.

This is starting to sound a lot like reference counting, and there are 
many implementations out there that use reference counting 
"automatically", most notably Swift. I'm not aware of any concurrent 
thread-safe implementation though, which would be nice if it can be 
achieved in general, but even if that works out, I'm assuming we could 
still end up with reference cycles. What's your thoughts on that 
subject? CPython deals with those with GC...

Samuel

On 5/30/21 2:15 AM, Maurizio Cimadamore wrote:
> 
> On 29/05/2021 15:35, Chris Vest wrote:
>> Hi,
>> It's not clear to me why the Handle acquire/release API is inferior to 
>> this new proposal, or why it can't solve the use cases discussed.
>> Looks fine, otherwise.
> Hi Chris,
> the acquire/release is not inferior in any way. Expressiveness-wise they 
> do exactly the same thing. As I said in another email, there is a bit 
> less cost in the sense that not having an explicit release remove costs 
> associated to make sure that you cannot release multiple times (which is 
> an extra CAS in the shared case). But these are small things.
> 
> The approach described in this document is an attempt to simplify the 
> API a bit. I think the code in the proposal looks a bit better 
> (especially when looking at how the NIO code can be simplified) and, 
> more importantly, for the user, reasoning in terms of temporal 
> dependencies between scopes is, I think, more intuitive than thinking 
> about incrementing and decrementing a counter. So I was trying to offer 
> an API which did the same thing as acquire/release, but in a way that 
> (perhaps!) could be more easily understood.
> 
> But under the hood we still have counters and acquires and releases: 
> this is (just) a discussion on how to better surface them to clients.
> 
> Maurizio
>>
>> Cheers,
>> Chris
>>
>> On Fri, 28 May 2021 at 18:34, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>     Hi,
>>     we've been looking beyond 17 at things we can do to improve support for
>>     resource scopes, especially in the context of native calls. I tried to
>>     capture the various things we explored in the writeup below:
>>
>>     https://inside.java/2021/05/28/taming-resource-scopes/
>>     
>>     I think overall the takeaway points are pretty good:
>>
>>     * we can simplify the acquire/release scope mechanism with a better, higher-level API
>>     * we can enhance safety when calling native functions using _any kind_
>>     of resource scopes (with relatively little overhead)
>>     * we can make it easier to tailor the safety characteristics of CLinker
>>     to suit application needs
>>
>>     Cheers
>>     Maurizio
>>