[mpiwg-languages] static datatypes lifetimes

[Ghosh, Sayan]

Thoughts on session ErrorHandler for releasing datatypes? From this diagram (in section 9.3), it seems the prevailing thought is to use session callbacks just like communicator callbacks.

[cid:image001.png at 01DBB762.FCD272D0]

--
Sayan Ghosh
Computer Scientist
Future Computing Technologies Group
Pacific Northwest National Laboratory
(509)-372-6323 • https://urldefense.us/v3/__https://sg0.github.io__;!!G_uCfscf7eWS!bYfNlyALFNovgdJlu80DwJzURGZflBW1we5P0JWxAqTaEm0uD1g5wDddcx4ccm-AtWABzf-t29R-nNDL-GNKql6M-muhU7KgwfdYSw$ 


From: mpiwg-languages <mpiwg-languages-bounces at lists.mpi-forum.org> on behalf of Joseph Schuchart via mpiwg-languages <mpiwg-languages at lists.mpi-forum.org>
Date: Saturday, April 26, 2025 at 7:51 PM
To: mpiwg-languages at lists.mpi-forum.org <mpiwg-languages at lists.mpi-forum.org>
Cc: Joseph Schuchart <joseph.schuchart at stonybrook.edu>
Subject: Re: [mpiwg-languages] static datatypes lifetimes
Check twice before you click! This email originated from outside PNNL.

Unfortunately, there is a catch: MPI_COMM_SELF is only relevant/available/valid in the World Process Model (WPM), i. e. , if using `MPI_Init`/`MPI_Finalize`. In the Sessions process model, predefined communicators are not available. The life-time
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Unfortunately, there is a catch: MPI_COMM_SELF is only

relevant/available/valid in the World Process Model (WPM), i.e., if

using `MPI_Init`/`MPI_Finalize`. In the Sessions process model,

predefined communicators are not available.



The life-time of datatypes is a known quirk and I think it was

discovered after Sessions became part of the standard. They are not

bound to any other MPI object and can survive complete shutdown of all

sessions / the WPM. IIRC in Open MPI (but have to check), datatypes

retain a reference on the internal MPI instance and it is the

application's responsibility to free all MPI objects before shutdown.

Once the last datatype/session/wpm is gone we release the instance.



I don't like the state of things there and it is problematic. For

starters, it prevents complete session isolation (and the benefits that

come with it, such as different threading levels). It's not clear to me

how that can be rectified and I think the Forum is not clear on that

either, which is why we ended up with this weird zombie state. If

someone wants to open a ticket to start a discussion on this I'm happy

to participate.



For the problem at hand though (as I understand it), maybe it's

sufficient to add attributes to datatypes? I don't see why that would be

a problem and if it helps with language adoption we have a good argument

for it.



Cheers

Joseph



On 4/25/25 17:24, Alfredo Correa via mpiwg-languages wrote:

> Hi Sayan, On Fri, Apr 25, 2025 at 2: 03 PM Ghosh, Sayan

> <sayan. ghosh@ pnnl. gov> wrote: Consider finalize-delete-callback

> (this is what Alfredo is alluding to perhaps w. r. t

> datatype-attached-to-environment) – that seems to rely on MPI_COMM_SELF

> ZjQcmQRYFpfptBannerStart

> This Message Is From an External Sender

> This message came from outside your organization.

> ZjQcmQRYFpfptBannerEnd

> Hi Sayan,

>

> On Fri, Apr 25, 2025 at 2:03 PM Ghosh, Sayan <sayan.ghosh at pnnl.gov> wrote:

>

>       * Consider finalize-delete-callback (this is what Alfredo is

>         alluding to perhaps w.r.t datatype-attached-to-environment) –

>         that seems to rely on MPI_COMM_SELF callback (freeing

>         comm-self triggers callback)

>

>

>

> That is a good point. At first glance, attaching things to

> MPI_COMM_WORLD or MPI_COMM_SELF would have a similar effect to

> attaching stuff to the environment.

> I didn't think about this because I was reluctant to modify (in any

> way) either of these special communicators, in particular MPI_COMM_WORLD.

> But MPI_COMM_SELF might still be a good candidate; others can point

> out if there is a catch.

>

> Thanks,

> Alfredo

> _

> _

>

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-languages/attachments/20250427/2a03111a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 327718 bytes
Desc: image001.png
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-languages/attachments/20250427/2a03111a/attachment-0001.png>