Filter called more than once...
Havoc Pennington
hp at redhat.com
Tue Mar 6 19:32:37 PST 2007
Krishna R wrote:
> The problem seems to be with me returning
> DBUS_HANDLER_RESULT_NOT_YET_HANDLED in the filter func! Atleast the
> problem went away when i changed it to HANDLED.
>
> Questions:
>
> How is NOT_YET_HANDLED supposed to work?
For a single message there may be multiple handlers that apply; if one
of them returns HANDLED, then additional handlers would not be called.
In general NOT_YET_HANDLED is correct for signals, because usually
everyone interested in a signal should get it. Usually HANDLED is
correct for method calls (assuming you really handled it, i.e. sent a
method return message). If nobody returns HANDLED for a method call,
then libdbus will send an error reply to that call as a default way of
handling it.
> 1. It should not call the same recv function again if it already
> returned NOT_YET _HANDLED. Correct?
Yes. The only exception I can think of is that if there's an
out-of-memory error during dispatch, it's possible the dispatch restarts
with the first handler. I'm not sure how this works offhand.
> 2. If a signal is sent out and 2 process are listening for it, if one
> process handles the signal and return HANDLED will the other process
> still get the signal?
The handlers in one process will have no effect on any other process.
The HANDLED/NOT_YET_HANDLED return value only controls which handlers
libdbus will call in the current process.
> Unrelated to the above problem,
> I read in one of the email threads here that if this kind of stuff is
> done, you need to do dbus_threads_init_default().
It could be related, if you had two threads and no locking, then you
might expect things to go haywire which might include dispatching the
same message twice.
> Is there a
> corresponding deinit() when the thread is killed?
Only dbus_shutdown() which shuts down the entire library (you must
free/unref any memory from libdbus that you own, prior to dbus_shutdown())
threads_init and dbus_shutdown() are for the whole process, not for
individual threads.
Havoc
More information about the dbus
mailing list