Protezione dalla reentrancy nelle funzioni hook

Anche se una funzione hook elabora un evento, è possibile attivare eventi aggiuntivi, che possono causare la riattivazione della funzione hook prima del completamento dell'elaborazione dell'evento originale. Il problema della reentrancy nelle funzioni hook è che gli eventi vengono completati fuori dalla sequenza a meno che la funzione hook gestisce questa situazione.

Si consideri ad esempio un caso in cui una funzione hook in un programma di lettura dello schermo elabora l'evento EVENT_OBJECT_VALUECHANGE per un controllo di modifica. Se, durante l'elaborazione del primo evento di modifica del valore, la funzione hook viene nuovamente immessa per elaborare un evento di modifica del valore successivo, il secondo evento viene completato prima del primo evento. Questa situazione genera l'utilità di lettura dello schermo che trasmette informazioni non corrette all'utente.

Poiché l'elaborazione degli eventi viene interrotta, gli eventi aggiuntivi potrebbero essere ricevuti ogni volta che la funzione hook chiama una funzione che causa la verifica della coda del messaggio del thread proprietario. Ciò accade quando uno dei seguenti viene chiamato all'interno della funzione hook:

• Funzione Windows SendMessage, GetMessage, PeekMessage, DialogBox o MessageBox
• Funzioni di accessibilità Microsoft ActiveObjectFromEvent, AccessibleObjectFromWindow, AccessibleObjectFromPoint
• Un'interfaccia IAccessibile o un altro metodo COM (Component Object Model) che supera i limiti di processo

Poiché le funzioni hook chiamano le proprietà e i metodi AccessibleObjectFromEvent e IAccessibile , non è possibile impedire la reentrancy. L'unica soluzione è per gli sviluppatori client per aggiungere codice nella funzione hook che rileva la reentrancy e intraprendere un'azione appropriata se la funzione di hook viene immessa di nuovo.