On 02/03/15 18:08, Lukasz Stanislawski wrote: > Hello everyone, > > Currently, I'm developing small C application using libatspi and > encountered some problems with event processing. > > What I have is two event listeners A and B registered with > atspi_event_listener_register() on different at-spi events. Inside > main loop assume that A listener can invoke callback a() on some atspi > event. Inside a() callback there are some calls to > atspi_accessible_get_* functions. > > What I have noticed is that calling functins like. > atspi_accessible_get_name() triggers further dbus events processing > what result in different listeners to be invoked.
Those get functions need to trigger those dbus events, as the information is usually not stored (except if it is already cached) at libatspi. It needs to be requested to the client (the application). So it is not possible to avoid that dbus triggering, as is the only way to get the info you request. > As the result code of b() callback can be invoked (and sometimes is in > my application) during execution of a() callback code. About getting the other callback called because a different listener is invoked: it is complicated to understand your problem at a so abstract level. Could you give a example of what event is triggered when atspi_accessible_get_<something> that invokes the second callback? > > I find this very inconvenient because every atspi_accessible_get_* > related call in callback a() have to be wrapped with some 'rollback' > logic in my application, because events of listener B can occur. > > So my questions are: > > 1. What is a preferred way of handling such cases? I want every > callback to process sequentially and not to introduce new race > conditions in my application. Such APIs makes my code hard to write > because "everything can happen everywhere". As mentioned, if in your callback you call new atspi methods, they would need to use dbus to get that info. But it would be good to have a real example in order to know why this is problematic. > 2. Shouldn't it be better to dispatch all deferred events when main > loop enters idle state? Mayby there is a reasoning for such design > that I'm not familiar of. You seem to suggest the addition of an asynchronous API. If that is the case, it is true that there are some attempts to include an asynchronous API in order to solve some issues of the classic libatspi synchronous API. But in most cases, libatspi is still an asynchronous API. BR -- Alejandro Piñeiro (apinhe...@igalia.com) _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
