Hi Joseph, Thanks for bringing this back to mind. Apologies for drop ping the ball :) To clarify and to refresh my memory of previous discussions: 1) The new request type, called a continuation, is only “floating” until it is bound to an MPI operation, right? 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.) 2) Can a single continuation request be bound to more than one MPI operation at the same time? 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. 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? I would adjust the WPM session handle 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. 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. The only mandated pset names are “mpi://world <mpi://world>” and “mpi://self <mpi://self>” which have obvious meanings in the world model, so the minimal compliant outcomes of MPI_SESSION_GET_NUM_PSETS and MPI_SESSION_GET_NTH_PSET seem straightforward. 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. 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? Cheers, Dan. — Dr Daniel Holmes PhD Executive Director Chief Technology Officer CHI Ltd [email protected]
On 1 Dec 2021, at 15:26, Joseph Schuchart via mpiwg-sessions <[email protected]> wrote:
Ping. Any opinions/inputs on this?
Thanks Joseph
-------- Forwarded Message -------- Subject: WPM Session Handle Date: Sun, 31 Oct 2021 11:08:06 -0400 From: Joseph Schuchart <[email protected]> To: mpiwg-sessions <[email protected]>
Hi all,
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.
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.
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?
Thanks Joseph _______________________________________________ mpiwg-sessions mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions