dissecting memory sessions

[Maurizio Cimadamore]

On 03/11/2022 13:00, Sebastian Stenzel wrote:
> (Unless there is a way for threads to respect a hierarchy (like parent 
> and child processes), where access could be restricted to scopes 
> created by ancestors. But I don't think this is how threads work. And 
> if it was feasible in Java, it would still break in my use case which 
> involves foreign threads, I guess.)

Assuming I understand correctly, this is what structured sessions are 
all about (and threads forked by a StructuredTaskScope in general).

These threads do support nesting - so, if you have a StructuredTaskScope 
ST2 nested inside another StructuredTaskScope ST1, the threads forked 
from ST2 are seen as "children" of ST1. This has some important 
consequences:

* threads in ST2 can see the same "scoped values" values as those in ST1 
(see [1])
* ST1 cannot be closed untill all threads in ST2 terminate (or a 
StructureViolationException will occur)

As it turns out, these principles are not only useful for organizing 
computation across threads, but also to reason about memory ownership: 
if a segment is created in a structured memory session SM2, which is 
nested inside another structured session SM1, then all threads forked 
from a StructuredTaskScope inside SM2 can freely access the segment - 
because there's a strong guarantee that the segment cannot be closed 
while SM2 is alive.

Unfortunately, in your case threads are created/attached asynchronously, 
from native code, so all the nice structural guarantees go out of the 
window. As the document outlines, it is possible to come up with a story 
to set up parent-child relationship between _unstructured_ memory 
sessions as well. But the use cases where this is useful are not many 
(especially if we consider a word where we support structured sessions), 
so we'd like to wait a bit more to see if this is something clients 
really need, before adding more API surface.

Thanks
Maurizio

[1] - https://openjdk.org/jeps/429