Re: libatspi and event processing



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 (apinheiro igalia com)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]