Waiting for exit

[seanpearsonuk]

          I'd like to start a discussion about this.  What might be useful here? 

>>> exit_status = solver.exit_async(on_exit_complete = exit_cb) # optional callback
>>> exit_status()
<ExitStatus.IN_PROGRESS>
>>> exit_status.time_taken
1.5
>>> exit_status()
<ExitStatus.COMPLETE>

callback can be called every time the status changes e.g., IN_PROGRESS, COMPLETE + any realistically detectable error scenarios.

The idea is to give the caller fine control without complicating the interface, and without blocking access to Python.

Originally posted by @seanpearsonuk in #2029 (comment)

[raph-luc]

My initial thought is that example with a callback looks a little overcomplicated for the issue linked to the PR. For example, I believe it usually won't matter to users the specifics of how long the Fluent exit process takes, or the exit-progress status changes.

What I would expect most users will actually care about is whether the Fluent processes have completely finished or not (so they can move files, etc.), and that can be addressed with a single argument addition inside the already used session.exit() as suggested in the PR.

Is there a scenario/example where a completely asynchronous exit would make more sense? As in the issue mentioned above, the user was already expecting the session.exit() command to lock the interpreter up until Fluent had completely finished, so locking the interpreter is not necessarily an issue nor unexpected.

Our existing session.exit() is already somewhat asynchronous by the way, the only reason why it may lock up (and require the timeout functionality so it's not a permanent freeze in some conditions) is when the gRPC exit request locks up. As long as Fluent is responding, that request won't block the interpreter, so Fluent will exit asynchronously in the background, after a session.exit(), without blocking access to Python.