search

JKISoftware / JKI-State-Machine-Objects

Object-oriented framework for LabVIEW based on the JKI State Machine
BSD 3-Clause "New" or "Revised" License
96 stars 55 forks source link

Stopping dependencies should gracefully handle errors with aggregated dependencies #21

Closed francois-normandin closed 7 years ago

francois-normandin commented 7 years ago

ex: A starts B and C. B then depends on C. A stops... which destroys C before stopping B. B errors out with 1556 error, even though it is not responsible for B's lifetime.

francois-normandin commented 7 years ago

Temporarily fixed issue (1.1.8+) by discarding error 1556 in the onStop( ) loop for stopping and destroying dependencies. In the future, these errors should not occur if the base process handles dependency management (not implemented yet). Keep case opened until it is done.

drjdpowell commented 7 years ago

If B depends on C running, then shouldn’t A start C before B, and shutdown B before C?

francois-normandin commented 7 years ago

Short answer: Yes it should, and it will if they are statically defined as dependencies of A and set to start in the proper order.

However, a confusion could occur if they are added dynamically to a list of dependencies at runtime. Take the example of a smartphone which shares a Camera subsystem with any app that has been granted access to the shared resource: Camera is started and App "X" depends on it, but then Camera is unexpected stopped. App "X" would error when it tries to use Camera API, and its normal behavior might be to stop itself. When it stops, it first sends a request for all its dependencies to stop themselves first. Now, if Camera's lifetime is owned by another subsystem, it would normally reject a request to stop (X cannot stop Camera). The fix was to ignore a 1556 error only when stopping dependencies as there are two cases we need to account for: 1) the dependency is already destroyed (1556 error, invalid reference) or 2) we don't own Camera's lifetime, therefore we don't care if it is a dead reference. In either case, we can ignore the 1556 error on stopping dependencies.

A more rugged approach might be that we need to wait for anyone depending on an aggregated resource to stop before stopping said resource. The SMO framework could be modified to account for this, but it would still be possible for a shared resource to stop unexpectedly and the framework should allow another subsystem to gracefully shutdown when that happens.

francois-normandin commented 7 years ago

will be covered by Feature 16.