You could have the sequencing of the command and the subcommand happen in the calling process:
def SequencedOperations do
use GenServer
def run_simple_command(...etc...) do
GenServer.call(...)
end
def run_complicated_command(...) do
result1 = run_simple_command(...)
run_other_simple_command(..., result1)
end
# handle_call etc
end
The client still sees a simple blocking API - SequencedOperations.run_complicated_command() and the GenServer is solely responsible for holding the state of the connection to the external binary.
Something to think about regarding doing this asynchronously: what happens if another call comes in when a command is currently running? Does it go into a queue somehow? What’s the observable state of the GenServer “mid-command”?
At work we tried a similar asynchronous pattern in a complex state machine, and it was a mess - suddenly the async reply could arrive after the machine changed state, and the possible combinations got really unwieldy. In your case, consider simplifying the GenServer to selectively receive just the {:stdout, _, _} message:
def handle_call({:do_thing, arg1}, from, state) do
# send command
# ...
receive do
{:stdout, _, reply_value} ->
# do something with reply_value and reply to from
{:DOWN, _, _, _, reason} ->
# uh-oh the process went away
# could also let this sit in the mailbox and have a top-level handler for it, with different timeout behavior
after
10000 ->
# timed out!
end
To answer the previous questions, this approach:
- relies on the process mailbox to store calls that arrive while one is already in-flight
- the state is only observable when a command is not in-flight
