Create effective atomicity between external interfaces such as events and factories

[eric@adblockplus.org]

Background

The plugin relies on multiple source of external events to function, and these events must all be present for proper operation. Principal among these are COM events from the BHO site, a IWebBrowser2 interface, and the two factories for APP protocols. Ideally, these should be enable and disabled atomically, so that it's never the case that one is on and one is off. In our present code, though, there are potential race conditions where this situation is possible.

It's actually more complicated than that, since the APP factories are registered on a per-process basis, the protocol instances from these factories are on the basis of a policy inside IE, and the COM events on a per-instance basis.

Unfortunately, there's nothing like a transaction manager that can provide atomicity through an API. Instead, we'll need to simulate the effect of an atomic change by altering the behavior of the components, allowing them both a "do nothing" and "do something" state. We may not be able to atomically change the registrations, but we can atomically change between enabled and disabled states.

What to change

For each relevant component, add an enable-disable flag to the appropriate class definition. For each of these flags, implement an appropriate "do-nothing" behavior. For COM events, that means simply ignoring the events. For APP factories, it's rather more complicated. We can unregister the factories entirely, have the factory provide only a default implementation, have the factory provide disabled protocol objects, or some combination of these.

Create a facility that enables the desired atomicity. That facility can take most any form, but it should be properly encapsulated so that the changes are always made consistently.

Ensure atomicity in all the situation where it matters: around life cycle events (construction/destruction/SetSite), disabling because of an error condition (for example, failure of detached initialization), enabling/disabling by explicit user action.

[ansonn]

spam