An application such as Orca may itself expose information via atk. Cur
rently, if orca is run, pyatspi will deadlock when it tries to call methods on itself. Dbind has code to work around this for cspi (it will call dbus_message_read_write_dispatch if the destination is the same as the sender). An approach like this will not currently work with dbus-python because it calls dbus_bus_get_private for its connection.
I think that we will need to modify dbus-python to add a flag in DBusConnection and the bindings to optionally call dbus_bus_get rather than dbus_bus_get_private, but I wanted to file a bug here to track the issue for at-spi and see if anyone reading this had any other suggestions.
Author: Mark Doffman <mdoff@silver-wind.(none)>
Date: Tue Mar 3 17:06:57 2009 +0000
2009-03-03 Mark Doffman <firstname.lastname@example.org>
Add a hack so that the AT is not accessible
over AT-SPI. This is until pyatspi has re-entrant
This commit adds a work-around for the problem. Within pyatspi the AT is not accessible. (Cannot call itself)
Added re-entrancy for all D-Bus methods. Applications using pyatspi may now inspect AT-SPI methods in the same process.
*** Bug 20430 has been marked as a duplicate of this bug. ***
tested in release 06-09-2015 , working as per its functionality