No subject

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.

Kind regards,
Tim Wuyts
Sr. Developer
Fifthplay


On 10/16/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> 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.
>
> Havoc
>
>