[foreign-memaccess] API refinements

[Paul Sandoz]

The trick I was trying to pull off, which does not seem to be working :-), is to define temporal confinement as well as thread confinement.  In that sense a segment returned by “acquire” is a thread-confined *and* temporally-confined view, be it owned by a different thread or otherwise.

Status quo is ok by me.

Paul.

> On Jan 6, 2020, at 3:07 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> 
>>> * MemorySegment::acquire() -- replace with MemorySegment::fork?
>>> 
>>> I came up with that - and I think I still like it. Acquire seems to suggest that it has something to do with threads and ownership - which it does, but in reality you can acquire a segment even from same owner. Fork seems a more neutral term, and, to me helps better visualizing what's really going on (e.g. a tree of segments is being created).
>>> 
>> 
>> Not sure about fork, it reminds me of processes or fork-join, something that is task oriented, overloaded term… but I think it could grow on me.
>> 
>> Re-reading the JavaDoc, we could refer to it as a confined view and call the method asConfined and s/acquired memory segment/confined view memory segment”.
> Not too sure. For two reasons: (i) it seems to suggest that the segment it came from it wasn't confined (they all are, in a way) and, more importantly (ii) because the 'asXYZ' naming convention implies a 'dumb' view which, if closed, closes everything, which is not the case here (this is why slice() has been renamed to asSlice()).
> 
> So, while we could call it confine(), the problem is that this method is effectively doing two things:
> 
> 1) create a new sub-segment whose life-cycle controls that of the parent
> 2) give a new confinement owner to the new sub-segment
> 
> Seems to me than names like acquire() and confine() suggest a string bias for (1), whereas fork() is probably biased for (2).
> 
> The problem with bias is that names like acquire() or confine() make perfect sense in a share context, but makes little sense when used in a single thread context, where you might want to use the acquire mechanism as a way to e.g. make sure that you can't close the parent segment before all the slices have been closed. In those case a name like fork() works better.
> 
> I'm fine with keeping acquire() if nobody comes up with a better alternative.
>