RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator)

[Maurizio Cimadamore]

On 30/04/2020 01:06, Peter Levart wrote:
> Think differently: what if the client succeeded in closing the 
> segment, just because it did it in a time window when no thread in the 
> thread pool held an open scope (this is entirely possible with 
> parallel stream for example since threads periodically acquire and 
> close scopes). This would have the same effect on threads in the 
> thread pool - they would not be able to continue their work... What 
> I'm trying to say is that this is just a mechanism to make things 
> safe, not to coordinate work. If program wants to avoid trouble, it 
> must carefully coordinate work of threads. 

This appear to me to be a bit of a slippery slope? Sure, if somebody 
prematurely calls close() on a segment while other threads are accessing 
it, it could be seen as undefined behavior (a la C specifications ;-) ), 
but then, if you pull on the same string, why even bother with 
confinement in the first place? If you call close() prematurely and you 
get a VM crash that's on you?

Maurizio