Re: AXObserverRemoveNotification sometimes painfully slow [Follow up to] Hidden Cocoa apps have empty kAXWindowsAttribute
Re: AXObserverRemoveNotification sometimes painfully slow [Follow up to] Hidden Cocoa apps have empty kAXWindowsAttribute
- Subject: Re: AXObserverRemoveNotification sometimes painfully slow [Follow up to] Hidden Cocoa apps have empty kAXWindowsAttribute
- From: Eric Schlegel <email@hidden>
- Date: Wed, 26 Mar 2003 06:14:31 -0800
On Wednesday, March 26, 2003, at 04:55 AM, Matt Gough wrote:
Anytime an AX API is called on an element, some interprocess
communication
has to happen between the two apps involved. Since this can't just
pre-empt
what the window owning app is doing such calls have to be handled
inside its
CFRunLoop.
This is true.
Unfortunately during app hiding, this mechanism cannot fire and
the two apps get into a semi-deadlocked state until
AXObserverRemoveNotification times out.
I don't know enough about how this works in Cocoa to say whether this
is true. Mike would know better.
So is there a solution to this that prevents this hanging?
My idea would be: keep a global NSTimer object around and release the
observers from the timer. When you get the WindowDestroyed
notification, if you haven't created the timer yet, create it and give
it a short delay; if you have created it already, reset the timer's
fire time to be the current time plus the delay. Hopefully that way the
timer won't fire until all of the notifications have been received, and
at that point, you can release all of the observers.
How much of a memory leak are we talking about by not removing the
observer,
and where does the leak occur (in my app, the other app, or the system
in
general?)
I think it would be in both your app and the observed app.
-eric
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.