Implicit scope handle

[Radosław Smogura]

Hi,

Conceptually, at least for purpose of documentation we could divide handles to explicit and implicit handles.

Such handle can be lazily created with implicit scope, and returned as singleton (it’s still, will not be so fast as compile time constant), but will be something closer to handles.

If we don’t want handles to be autoclosable than implicit scope can implement handle, and aquire would return this.

Then, documentation can describe differences, and say that the best way to manage any scope is to release handle, and make reference unreachable.

BR,
Rado

> On Apr 26, 2021, at 11:17 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Sure - but then:
> 
> ```
> * Acquiring implicit resource scopes is also possible, but it is often unnecessary: since resources associated with
>  * an implicit scope will only be released when the scope becomes <a href="../../../java/lang/ref/package.html#reachability">unreachable</a>,
>  * clients can use e.g. {@link java.lang.ref.Reference#reachabilityFence(Object)} to make sure that resources associated
>  * with implicit scopes are not released prematurely. That said, the above code snippet works (trivially) for implicit scopes too.
> ```
> 
> Yes, splitting ResourceScope in implicit vs. explicit is a move that seems to help at first and we've thought about it - until you start thinking about how clients will write a critical region. That would mean clients would need an instanceof check and, if scope is shared, they need an acquire, etc.
> 
> What we have now is strange, I agree, but works uniformly regardless of the scope kind - and doesn't introduce extra overhead when it's not required (implicit scopes). It is a very fine line we're walking here, and I don't think there's any "slamdunk". In the end we opted for uniformity in client code: if you receive a segment you don't care whether it's shared, confined, implicit or not. If you have a piece of code that would break if the scope is closed (as it's the case for NIO bytebuffer operations) just wrap your usage in a try/finally with acquire/release.
> 
> Maurizio
> 
>> On 26/04/2021 21:40, Radosław Smogura wrote:
>> Hi,
>> 
>> I know that I’m slightly goes in too many details.
>> 
>> In docs it’s “ A resource scope handle can be used to make sure that resources associated with a given resource scope
>>  * (either explicit or implicit) cannot be released for a certain period of time”
>> 
>> I think this could be a bit misleading.
>> 
>> Now I wonder that maybe easiest solution would be to divide ResourceScope into two sub interfaces (not nessesery now).
>> 
>> This way the performance of implicit scope can be kept the same (maybe even better), and as well API will be more consistent?
>> 
>> Kind regards,
>> Rado
>> 
>> 
>>>> On Apr 26, 2021, at 10:11 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>> 
>>> That is all documented in the javadoc - e.g. acquiring an implicit scope is essentially a no-op. The only thing we guarantee is that if you use this idiom:
>>> 
>>> ```
>>> var handle = scope.acquire();
>>> try {
>>>    // critical region
>>> } finally {
>>>    scope.release(handle);
>>> }
>>> ```
>>> 
>>> the scope will not be closed inside the critical region (because of the reachability fence inside the `release` method).
>>> 
>>> Maurizio
>>> 
>>>> On 26/04/2021 19:44, Radosław Smogura wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I think this is last thing I noticed.
>>>> 
>>>> The implicit scope’s handle may not work correctly and prevent garbage collection from happening.
>>>> 
>>>> Right now the shared handle is returns what it’s ok for global scope.
>>>> 
>>>> For separately create implicit scope, I think new handle should be created, having reference to the scope which can be cleared on close.
>>>> 
>>>> Best regards,
>>>> Radoq