Guarding Against Reentrancy in Hook Functions
While a hook function processes an event, additional events may be triggered, which may cause the hook function to reenter before the processing for the original event is finished. The problem with reentrancy in hook functions is that events are completed out of sequence unless the hook function handles this situation.
For example, a hook function in a screen reader program is processing the EVENT_OBJECT_VALUECHANGE event for an edit control. If, while processing the first value change event, the hook function is reentered to process a subsequent value change event, it completes the second event before the first event. This situation results in the screen reader conveying inaccurate information to the user.
Because event processing is interrupted, additional events might be received any time the hook function calls an API that causes the owning thread's message queue to get checked. This happens when any of the following are called within the hook function:
- The Win32 APIs SendMessage, GetMessage, PeekMessage, DialogBox, or MessageBox
- The Active Accessibility APIs AccessibleObjectFromEvent, AccessibleObjectFromWindow, AccessibleObjectFromPoint
- An IAccessible interface or other COM property or method that crosses process boundaries
Because hook functions call AccessibleObjectFromEvent and IAccessible properties and methods, it is not possible to prevent reentrancy. The only solution is for client developers to add code in the hook function that detects reentrancy and take appropriate action if the hook function is reentered.