[foreign-memaccess] RFC: to scope or not to scope?

[Maurizio Cimadamore]

On 01/06/2019 16:50, Jorn Vernee wrote:
> For asConfined() creating a view segment would not work, since the 
> root segment, which holds the liveliness flag, would not be confined 
> to a single thread. For asConfined to work as expected I believe we 
> would have to kill the root segment, effectively transferring the 
> underlying resource to the newly created confined segment. This also 
> brings up an idea I had been thinking about; make thread confined-ness 
> a more local, temporary state. e.g. you call asConfined which creates 
> a segment that is confined to the current thread, but then add a 
> release() method that invalidates the confined copy and makes the root 
> segment valid again. This could be used around loops, e.g.: 

I don't think I agree with this line of thought. The use I have in mind 
for this API is something like:

try (MemorySegment segment = MemorySegment.ofNative(bytes).asConfined()) 
{ ... }

If you do this, then inside the try with resources you have the 
guarantee that everything will be confined.

We could of course enforce a no-access state by default, or 
confined-by-default, but IMHO that's just adding additional hops for the 
(likely) case where these things don't make a difference. And, if you 
really want to make sure that what you have is confined, and there's no 
racy access possible, just call the view method as soon as you allocate 
the segment (as above), then nobody will be able to access to the 
non-confined version.

This is not different from how ByteBuffer::asReadOnly works - and I 
think that's a pragmatic compromise. That API too will have the same 
issues discussed here (if somebody keeps hold of the original BB, you 
can still write on a supposedly read-only buffer), but I wonder how much 
that is really a problem in practice, given that it can be avoided with 
some discipline.

As much as I agree with the theory that returning a no-access segment is 
the only way to make the API really tight, at the same time, I having 
factory methods that return what would effectively be unusable segments 
seems a weird API choice to me. At this point I think I would prefer 
having some 'flags' to be passed to the segment factory (pretty much 
like we had scope charateristics before).

Maurizio