Fix races in AsyncEventNotifier::execute
* m_aDeadProcessors was useless; for one, removeEventsForProcessor could never have run (and set m_aDeadProcessors) between execute's reading from aEvents and checking m_aDeadProcessors (because of the use of aMutex in both functions), and if that were addressed, there would always be a race that execute would run a processor that has just been removed. Clients have to be aware that a call to removeEventsForProcessor is just an optimization hint, but does not guarantee that the given processor is not called from the execute thread after removeEventsForProcessor returns. * The sequence aGuard.clear(); aPendingActions.reset(); aPanedingActions.wait(); could cause calls to aPendingActions.set() to get lost, both for signalling new content in the queue and for signalling termination. Change-Id: I43293e3d5090c2d46db8bc8ed6fb9c71e049d55c
Showing
Please
register
or
sign in
to comment