Synchronous method in asynchronous signal callback

[Marco Bascetta]

On 14/05/15 19:10, Marco Bascetta wrote:
>> dbus-glib is deprecated and should not be used, but
>> http://cgit.freedesktop.org/dbus/dbus-glib/tree/dbus/dbus-gmain.c does
>> provide an example of a complete main loop hookup including all the
>> necessary glue:
>>
>> * watches
>> * timeouts
>> * separate read and write watches for the same fd (yes this is silly,
>>    but the mainloop integration glue API doesn't give us a way to signal
>>    that the wants-read/wants-write state has changed, and I don't think
>>    we can assume that every existing implementation re-polls the flags
>>    when a watch is disabled and re-enabled)
>> * dbus_connection_set_wakeup_main_function(), which I think might be
>>    the one you're missing?
>>
>> [1] http://smcv.pseudorandom.co.uk/2008/11/nonblocking/
>> [2] e.g. http://skarnet.org/software/skalibs/libstddjb/selfpipe.html
> I'll try to follow the dbus-gmain.c implementation and your advices 
> and I let you know.
>
> Instead, I already saw dbus_connection_set_wakeup_main_function and it 
> wasn't useful.

Hi,
I extended my implementation with your suggestion based on dbus-gmain.c 
(also removing force_dispatch flag).
There wasn't any improvement in my issue, but I have to change my 
opinion about dbus_connection_set_wakeup_main_function.
I thought that would serve to wake up the poll in case of multithread or 
blocking calls, instead I noticed that it's always called for each new 
event (signals, method replies, etc.);
so I decided to call my (refactored) "dispach_func" both when the watch 
and when an fd associated to dbus_connection_set_wakeup_main_function 
are triggered.
In this way I don't see any delay in signal receiving.

Probably is the worst solution that I could find, but seems to work well.

Do you believe that there may be hidden issues?

Thanks for your support.

-- 
Marco Bascetta - Sadel SpA
Software Development
Via Serenari 1, Castel Maggiore (BO)