Implicit scope handle

[Maurizio Cimadamore]

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