On 3/1/26 6:22 PM, Eliot Courtney wrote:
On Sat Feb 28, 2026 at 3:11 PM JST, John Hubbard wrote:
On 2/26/26 7:50 AM, Eliot Courtney wrote:
Add sync and async command queue API and the type infrastructure to know
what reply is expected from each `CommandToGsp`.
Use a marker type `NoReply` which does not implement `MessageFromGsp` to
mark async commands which don't expect a response.
...
Hi John,
I totally agree and was hoping that someone would have a good suggestion
for this. I discussed this exact thing with Alex before posting this
too. So if you have any naming suggestions would love to hear them.
As you say, sync and async are orthogonal to reply vs no reply. I think
we have several ideas here actually:
- blocking vs non-blocking
- reply vs no-reply
- wait for reply vs don't wait for reply (practically equivalent to
blocking vs non-blocking here, but conceptually the send could also be
blocking vs non-blocking)
We should also be careful with conflating waiting for the reply vs not
having a reply. So `send_without_waiting_for_reply` is definitely
confusing to me, because there may be a reply that we just don't wait
for.
Some ideas:
- send_command_with_reply + send_command_without_reply
- Maybe non-obvious that this blocks for send_command_with_reply.
- send_and_wait_for_reply + send_no_reply
- More obvious that it blocks and gets the reply.
- Should be obvious from context that you are sending a command
anyway.
Personally I think it's nice to keep a convention of keeping it
mostly obvious which functions block/wait. (e.g. we already have
wait_for_msg in cmdq.rs).
For lack of a better idea i suggest send_and_wait_for_reply +
send_no_reply for now.
That sounds great, I'd love to start with that. Simple and clear.
One thing: "send no reply" sounds a lot like "do not send a reply". :)
So maybe:
send_and_wait_for_reply()
send_without_waiting_for_reply()
? Or something along those lines? It's really verbose I know...
thanks,
--
John Hubbard
