On 3/2/26 4:28 AM, Danilo Krummrich wrote:
On Sat Feb 28, 2026 at 7:11 AM CET, John Hubbard wrote:
The sync/async naming that GSP RM uses is a little bit "off". I
spent some time discussing it with them, and the problem is that
sync/async is a concept that is somewhat independent of whether
a reply is expected. Usually, sync means a blocking wait for a
response, which is not necessarily required in all case with
GSP RM calls.
The naming would be better here if it reflected simply that
a response is expected, or not. I don't have great names for
that, but "fire and forget" works well for what we have so
far called "async". So we could do create a convention in which
no annotation means that the API has a response that will come
back, and some abbreviated for of "fire and forget" or "one way"
added to the function name would mean that no response is
expected.
I think the relevant information for the caller is whether the call is blocking
or non-blocking; i.e. do we have cases where we want to block, but discard the
reply, or expect a reply but don't want to wait for it?
So, unless there is additional complexity I'm not aware of, I feel like
send_command() and send_command_no_wait() should be sufficient.
That's my favorite so far. It's unencumbered by any assumptions about
behavior, and unambiguous about what it does, and shorter names too.
(Maybe send_command_wait() if we want to be a bit more explicit.)
As for the specific commands, we could have traits to control whether blocking
or non-blocking submissions are allowed for them in the first place, i.e. this
gives us some control about whether a reply is allowed to be discarded through a
_no_wait() submission etc.
thanks,
--
John Hubbard
