Hi Phil,

Thanks for your question!

Calling a custom stack destructor for an unnamed ULT is possible within the current Argobots infrastructure. This is related to this issue: https://github.com/pmodels/argobots/issues/16.

For the detailed implementation, please find the complete code here (collapsed): https://github.com/pmodels/argobots/issues/274#issuecomment-785221242. Though you have to call init_stack_key() and finalize_stack_key() to use this, it should be simple enough: you just basically change allocate_stack() and free_stack() for your workload.

I believe this is the quick path to implement your idea. But maybe a more intuitive stack-free-hook interface would be preferable (this request is not the first time). Please let me know if you need such a new interface (especially if your idea works well).

Thanks,

Shintaro

On Wed, Nov 17, 2021 at 2:15 PM Phil Carns via discuss <discuss@lists.argobots.org> wrote:

Hi all,

We've been thinking about some memory optimizations for which it might
be easier if our own code provided the stack memory for newly created
ULTs so that we have full control over the allocation strategy. This
seems pretty straightforward with the ABT_thread_attr_set_stack() function:

https://www.argobots.org/doxygen/latest/d2/df6/group__ULT__ATTR.html#gac8f39be20d677898c45293c5ce31eea0

However, our use case often creates unnamed (detached) threads by
setting the ABT_thread_create() newthread argument to NULL. I can
elaborate if needed, but the short story is that this is a really
natural fit for RPC handlers in our model:

https://www.argobots.org/doxygen/latest/d0/d6d/group__ULT.html#ga73bd1f04ce57def336cb20cdec9b14bd

Is it possible to do both (provide an externally managed stack pointer,
and use unnamed ULTs)? From the documentation it looks like the answer
is probably no, because the caller who created the stack allocation
doesn't explicitly free the ULT, and thus doesn't have a way to free the
stack after the ULT is complete.

I wanted to double check though before I start thinking about
alternatives, though.

thanks!

-Phil

_______________________________________________
discuss mailing list
discuss@lists.argobots.org
https://lists.argobots.org/mailman/listinfo/discuss