taming resource scopes

[Maurizio Cimadamore]

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 
> <mailto: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/
>     <https://urldefense.com/v3/__https://inside.java/2021/05/28/taming-resource-scopes/__;!!GqivPVa7Brio!PmpHKfNwPjv0VCJl8yD6e5znprPFtrz6uDI6wMVDpjjTFzYajSuueD3xpBy3SEv893mZOd0$>
>
>     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
>