You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the only API really provided for stopping a solver "safely" is to catch a KeyboardInterrupt exception to shut down gracefully. This works well when run directly by users -- e.g. in a Jupyter notebook or Python script -- but causes issues when run in an event loop or on a separate thread due to the fact that signals are only delivered to the main thread.
This means that, if a simulation is run in a job queue like in Dask or on an asyncio event loop, the Python solvers cannot use the pause/resume functionality and the C solvers run the risk of the simulation subprocess not being stopped correctly.
The preferred approach for this would be to expose some sort of job control API so that the lifetime of the simulation can be explicitly managed. The existing run() methods would be intended for user-facing contexts, like Jupyter notebooks, and would simply be a synchronous, KeyboardInterrupt-enabled wrapper around this API.
The text was updated successfully, but these errors were encountered:
Currently, the only API really provided for stopping a solver "safely" is to catch a
KeyboardInterrupt
exception to shut down gracefully. This works well when run directly by users -- e.g. in a Jupyter notebook or Python script -- but causes issues when run in an event loop or on a separate thread due to the fact that signals are only delivered to the main thread.This means that, if a simulation is run in a job queue like in Dask or on an
asyncio
event loop, the Python solvers cannot use the pause/resume functionality and the C solvers run the risk of the simulation subprocess not being stopped correctly.The preferred approach for this would be to expose some sort of job control API so that the lifetime of the simulation can be explicitly managed. The existing
run()
methods would be intended for user-facing contexts, like Jupyter notebooks, and would simply be a synchronous,KeyboardInterrupt
-enabled wrapper around this API.The text was updated successfully, but these errors were encountered: