Wed Oct 17 02:25:55 PDT 2007
changing the timeout in the read_write to -1 and nothing else.
Unfortunately that simply doesn't work: messages are still being
'lost'. It's rather worrying that this behavior is not consistent:
sometimes messages get through, sometimes they don't.
Which brings me to my second question: using read_write_dispatch(-1)
and then using borrow_message, it all works flawlessly. This seems
unlogical: if the 'dispatch' part would drop the message, then there
wouldn't be anything to 'borrow' afterwards, would there?
And what really happens to the message in the queue after I return
(not steal) it? Does it get discarded (i.e. free'd), or does it keep
on consuming memory ad infinitum?
Sorry for all these questions, but I'm trying to get a grip on the way
dbus works: we're using dbus on an embedded system, so there can't be
any missing messages or memory leaks.
Thanks for your help.
On 10/16/07, Havoc Pennington <hp at redhat.com> wrote:
> Tim Wuyts wrote:
> > - // non blocking read of the next available message
> > - dbus_connection_read_write(conn, 0);
> > + // blocking read of the next available message
> > + dbus_connection_read_write_dispatch(conn, -1);
> > msg = dbus_connection_pop_message(conn);
> You changed two things here: you made it blocking (the -1) and you made
> it dispatch messages. If you dispatch a message, it won't be available
> to pop. So, you "lose" the message.
> If you install a handler for the message, e.g. with
> dbus_connection_register_fallback() or register_object_path(), then that
> handler would receive the message when you dispatch. But if you have no
> handlers, dispatching just drops the message.
> In short, you need to choose between dispatching to handlers, or
> bypassing all that and just popping messages off to handle them
> yourself. Doing both doesn't make sense.
More information about the dbus