<div dir="ltr"><div>Thank you for the detailed answer.</div><div><br></div><div>It's quite confusing that the segment can still be copied but not used in a method call. To understand it, it either requires detailed knowledge about the implementation or a new concept or state related to session and segments must documented.</div><div><br></div><div>Anyway, this would be even more cumbersome. So I'm sticking to other approaches for cleanup.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 14, 2022 at 11:59 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 14/09/2022 22:28, Manuel Bleichenbacher wrote:<br>
> The documentation for MemorySession.addCloseAction() states that the <br>
> order of custom cleanup actions is unspecified. But it only hints at <br>
> the order of custom close actions vs. closing memory segments.<br>
><br>
> Is it correct that memory segments are closed first, and then the <br>
> custom cleanup actions are executed?<br>
><br>
> If so, is there a specific reason for it? It would be more useful to <br>
> other way round.<br>
><br>
> I have several cases requiring cleanup of data structures residing in <br>
> a memory segment. It would be most natural to use custom cleanup <br>
> actions to do so as their lifespans end at the same time. But given <br>
> the current order, a far less elegant way is needed.<br>
<br>
The current spec says no ordering.<br>
<br>
In reality there is an ordering that can be relied upon (the javadoc <br>
will likley be rectified to reflect this).<br>
<br>
The actions added to the scope last will also be called first. Of course <br>
the ordering is only valid for actions added within the same thread, and <br>
if you have multiple threads adding action, other orders could be observed.<br>
<br>
When you allocate a memory segment using a session, a cleanup action for <br>
it is added to the session (as if calling addCloseAction), so you need <br>
to take that into account as well.<br>
<br>
Given all this, if you do:<br>
<br>
```<br>
MemorySegment.allocateNative(100, session);<br>
session.addCloseAction(runnable);<br>
```<br>
<br>
I would expect the "runnable" to be executed before "free" is called on <br>
the memory segment.<br>
<br>
But, mind you, that alone won't help much: from the perspective of the <br>
close action, the session attached to the segment has already been <br>
closed, so you cannot touch the segment directly (by the same token that <br>
protects from use after free). In other words, a session is a bit of <br>
state that is shared by all the resources attached to that session. When <br>
the session is closed (using the close() method), all the resources <br>
attached to that session becomes inaccessible at once. There's no way to <br>
add a "pre-close" action, because, if the action is pre-close, the <br>
session is still alive, and it means that other threads have potentially <br>
still access on the segment, and they might not know the segment is <br>
about to be closed (so the close action would race with other accesses, <br>
which seems a recipe for disaster).<br>
<br>
But the cleanup action can create a copy of the segment into a fresh <br>
segment associated with the global scope (using <br>
MemorySegment::ofAddress), and access that instead (since it knows the <br>
address still valid).<br>
<br>
Maurizio<br>
<br>
<br>
<br>
</blockquote></div>