When a user force kills an async job, any associated persistent qvm (or even the underlying qvm object), might be left in an inconsistent state. The same applies for exceptional situations where an error is signaled during execution. What should app-ng do in these cases? Options include:
Nothing, apart from documenting clearly in the kill-job RPC API endpoint docstring that no guarantees are made about qvm state after killing a job, and it's up to the user to call delete-qvm to remove the persistent qvm after.
Explicitly mark the persistent qvm as invalid, and prevent any future operations other than perhaps read-memory.
(1) is in keeping with the KISS philosophy and analogous to normal programming contexts where you don't necessarily expect an object to be in a valid state after an exception occurs.
(2) might help prevent frustration in case someone kills a long-running job in order to tweak the simulation, then mistakenly assumes they can safely re-start the job on the same persistent qvm, only to discover at the end that the results are garbage because the qvm started from an invalid state the second time around. Of course, (2) also adds more fiddly state tracking and complicates things for what will probably be an infrequent edge-case.
When a user force kills an async job, any associated persistent qvm (or even the underlying qvm object), might be left in an inconsistent state. The same applies for exceptional situations where an error is signaled during execution. What should app-ng do in these cases? Options include:
Nothing, apart from documenting clearly in the kill-job RPC API endpoint docstring that no guarantees are made about qvm state after killing a job, and it's up to the user to call delete-qvm to remove the persistent qvm after.
Explicitly mark the persistent qvm as invalid, and prevent any future operations other than perhaps read-memory.
(1) is in keeping with the KISS philosophy and analogous to normal programming contexts where you don't necessarily expect an object to be in a valid state after an exception occurs.
(2) might help prevent frustration in case someone kills a long-running job in order to tweak the simulation, then mistakenly assumes they can safely re-start the job on the same persistent qvm, only to discover at the end that the results are garbage because the qvm started from an invalid state the second time around. Of course, (2) also adds more fiddly state tracking and complicates things for what will probably be an infrequent edge-case.