Using PMIx_Get() with timeout not working?

[ashleypittman]

We're using a couple of newish keys in our client and occasionally we're seeing PMIx_Get() blocking, presumably because either due to an old server or a bug the key isn't found. What we'd like to do in this case is detect it and correctly abort. We're using a fence after Put so all gets should complete immediately.

I tried passing a info array into PMIx_Get and setting PMIX_TIMEOUT to either 0 or 1 as a PMIX_INT however this does not change the behaviour, unless we attach and then detach with a debugger, in which case PMIx_Get() returns -107.

I would expect a return code of PMIX_ERR_TIMEOUT (-16) in this case, and I would also like clarification of if 0 is a valid value to use for timeout here, if I expect the key to exist.

[rhc54]

Should have this fixed here: open-mpi/ompi#1981

[rhc54]

Here is the process I'm assuming you follow:

· Each proc PMIx_Put some data
· Each proc PMIx_Commit the data that it put
· Each proc PMIx_Fence and blocks until that completes
· Each proc calls PMIx_Get on the data for some other process, passing in PMIX_TIMEOUT=0 to indicate that it wants an immediate error return if the data isn’t found either in itself or on its local PMIx server. You don’t want the server to ask the RM to try and fetch it.

If the data was not in the client, nor available on the local server, then you will get a "not found" error back. This means that either the proc never put/commit it, or the fence wasn’t told to “collect all data”.

An alternative approach would be to let PMIX_TIMEOUT=0 mean "never timeout", and instead pass a new boolean PMIX_IMMEDIATE key to indicate that you want an immediate response. I'm open to either solution, so feel free to suggest your preference.

[ashleypittman]

As per email we're not calling PMIx_Commit() however we are using PMIX_COLLECT_DATA to PMIx_Fence(). Even with a change to calling PMIx_Commit() however we're still seeing the same behaviour.

[rhc54]

Just to clarify: are you getting the immediate response back that the data isn't found? So this issue is fixed, but the desired behavior to get the data that was pushed remains?

Or are you saying that the immediate response behavior is still broken?