Is there an automatic way to protect against “stale” DirectShow interface references?

Question

I just had a long debug session that was caused by a "stale" interface reference in my Delphi 6 DirectShow application that uses the DSPACK component library. As you know there are some operations that need to be done when the Filter Graph is active and others that are done to the component parameters when the Filter Graph must be inactive. The problem is that you can end up with DirectShow interface references that still have initialized values (assigned, not NIL), but aren't valid for the current Filter Graph incarnation because they were created during a previous incarnation of the Filter Graph. This isn't that hard to do, by accident, while turning the Filter Graph on and off to switch between "live" discovery operations and offline configuration operations. An example of an offline operation is setting the Moniker for one of the DSPACK components to use when it creates the concrete filter instance the next time the graph is turned on.

For example, you could have an IBaseFilter reference that you assigned when you first activated the Filter Graph, that you tried to re-use after de-activating and re-activating the Filter Graph. The interface reference is now "stale" because it does not belong to the current incarnation of the Filter Graph, but to a previous one. This leads to all kinds of weird and unintuitive DirectShow error messages that aren't what they seem but are really due to the interface reference being stale.

Has anybody come up with a way, whether by convention or by some clever solution like a DirectShow smart pointer tied to the lifetime of the Filter Graph, etc. to prevent this from happening? Or is the only solution to be relentlessly careful about interface reference usage?

Answer 1

As a filter developer you return error codes when a filter receives some processing request and it appears that the filter was already removed from graph, or changed its state.

From the application side, you are in control to implement any kind of sychnronization to indicate termination of operation. For example, before stopping/releasing a filter graph you can set a termination flag (boolean variable), and in a sort of processing callback which might be late and need synchronization you check the flag and you know when it is the time to abort processing due to outstanding termination request.