<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Joseph,<div class=""><br class=""></div><div class="">Thanks for bringing this back to mind. Apologies for drop ping the ball :)</div><div class=""><br class=""></div><div class="">To clarify and to refresh my memory of previous discussions:</div><div class=""><br class=""></div><div class="">1) The new request type, called a continuation, is only “floating” until it is bound to an MPI operation, right?</div><div class=""><br class=""></div><div class="">AFAIK, every MPI operation (*not* every MPI procedure) is “in” a single/particular session, because all MPI operations require one of the four central objects that provide nonlocal functionality. Thus, for a nontrivial continuation, i.e. for a continuation that actually continues an MPI operation, the association with a particular session is clearly defined already. Does the brief period of time during which it is, technically, “floating” matter? If so, how/why? (I can’t remember the discussion we had on this point.)</div><div class=""><br class=""></div><div class="">2) Can a single continuation request be bound to more than one MPI operation at the same time?</div><div class=""><br class=""></div><div class="">I can’t remember which way the continuations proposal lands on this design choice. Whichever choice is made, all MPI operations bound to a single continuation would have to be “in” the same session as each other, otherwise the isolation rule for sessions is breached. Specifying that session up front at creation-time for the continuation permits checking of the first MPI operation bound to it as well as the rest, whereas not specifying it explicitly means that the first MPI operation bound is always okay, but subsequent ones might be incompatible because of a session mismatch. Thus, isolation of sessions can be specified and enforced with implicit or with explicit selection of the session.</div><div class=""><br class=""></div><div class="">3) The idea of having a WPM session handle is almost entirely independent of the continuations proposal, although the latter might be able to make use of the former if it existed, right?</div><div class=""><br class=""></div><div class="">I would adjust the <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">WPM session handle </span>proposal to avoid a global symbol by providing instead a procedure that gave (a copy of) the WPM session handle. Global symbols created problems, c.f. the symbol MPI_COMM_WORLD w.r.t. FT.</div><div class=""><br class=""></div><div class="">The Sessions WG did not propose any mechanism to get a session handle for the world model because it would have added complexity to the MPI-4.0 discussions. We did, repeatedly, intimate that the world model is effectively like a session to which the user never gets a session handle. We even went as far as showing pseudo-code that implements MPI_INIT using MPI_SESSION_INIT so illustrate this point. The motivation there was to make the proposal less scary, rather than to offer this as new functionality for users of MPI. However, I don’t see any technical reasons why any MPI library could not provide a world model session handle.</div><div class=""><br class=""></div><div class="">The only mandated pset names are “<a href="mpi://world" class="">mpi://world</a>” and “<a href="mpi://self" class="">mpi://self</a>” which have obvious meanings in the world model, so the minimal compliant outcomes of MPI_SESSION_GET_NUM_PSETS and<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""> </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">MPI_SESSION_GET_NTH_PSET seem straightforward.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><font color="#000000" class="">We could make the actions of MPI_SESSION_[G|S]ET_ERRHANDLER (when called for the WPM session handle) be identical to MPI_COMM_[G|S]ET_ERRHANDLER (when called for the MPI_COMM_SELF communicator handle). Setting with one affects the result of getting with the other.</font></div><div class=""><font color="#000000" class=""><br class=""></font></div><div class=""><font color="#000000" class="">One point of possible contention would be: is calling MPI_SESSION_FINALIZE using the WPM session handle permitted and, if so, is it identical to (and a replacement for) calling MPI_FINALIZE? Specifically, if the WPM session is finalised, does the return value of MPI_FINALIZED change and is a subsequent call to MPI_FINALIZE erroneous?</font></div><div class=""><div class="">
<meta charset="UTF-8" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class="Apple-interchange-newline">Cheers,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Dan.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">—</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Dr Daniel Holmes PhD</div>Executive Director<br class="">Chief Technology Officer<br class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">CHI Ltd</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><a href="mailto:danholmes@chi.scot" class="">danholmes@chi.scot</a></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div></div><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 1 Dec 2021, at 15:26, Joseph Schuchart via mpiwg-sessions <<a href="mailto:mpiwg-sessions@lists.mpi-forum.org" class="">mpiwg-sessions@lists.mpi-forum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Ping. Any opinions/inputs on this?<br class=""><br class="">Thanks<br class="">Joseph<br class=""><br class=""><br class="">-------- Forwarded Message --------<br class="">Subject: <span class="Apple-tab-span" style="white-space:pre"> </span>WPM Session Handle<br class="">Date: <span class="Apple-tab-span" style="white-space:pre"> </span>Sun, 31 Oct 2021 11:08:06 -0400<br class="">From: <span class="Apple-tab-span" style="white-space:pre"> </span>Joseph Schuchart <<a href="mailto:schuchart@icl.utk.edu" class="">schuchart@icl.utk.edu</a>><br class="">To: <span class="Apple-tab-span" style="white-space:pre"> </span>mpiwg-sessions <<a href="mailto:mpiwg-sessions@lists.mpi-forum.org" class="">mpiwg-sessions@lists.mpi-forum.org</a>><br class=""><br class=""><br class=""><br class="">Hi all,<br class=""><br class="">The Hybrid-WG is currently discussing the Continuations proposal. Part of that proposal is a new continuation request type that is not bound to any communication operation, and thus not connected to any communicator, window, or file. That floating state is somewhat disatisfying. We are thus considering connecting it to a session, i.e., provide a session handle at creation. This would potentially allow us to isolate the execution of continuations from different sessions. Unfortunately, this is not possible at the moment because there is no default session handle for the WPM model.<br class=""><br class="">From my (arguably uninformed outside) point of view, the WPM is a special type of session worthy of its own handle (MPI_SESSION_WPM, for example), which can be used with all functions expecting session handles as input. As an example, `MPI_Session_get_info(MPI_SESSION_WPM)` would return an info object containing the "thread_level" info key and the value passed to MPI_Init_thread (or "single" for MPI_Init). I'm sure there are other more hairy procedures, but you get the point.<br class=""><br class="">Has this been discussed before? Was there a good reason not to have a WPM session handle? If not, can we add something like MPI_SESSION_WPM to allow future API extensions to use session handles?<br class=""><br class="">Thanks<br class="">Joseph<br class="">_______________________________________________<br class="">mpiwg-sessions mailing list<br class=""><a href="mailto:mpiwg-sessions@lists.mpi-forum.org" class="">mpiwg-sessions@lists.mpi-forum.org</a><br class="">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions<br class=""></div></div></blockquote></div><br class=""></div></body></html>