Performance of method calls in D-Bus GLib

[Abhijeet Kumar Sinha]

To overcome this, I tried with sending two method_call at a single go, that
didn't helped too. In some cases both the signals/method_call are lost, and
in some if I am lucky I get one of them. In most cases both the "duplicate"
signals/method_call were lost.

Is there a patch for this bug. If not can you direct me to the part of the
code which needs to be looked in-to ?

I don't have the luxury of having --print-reply because the dbus-send part
has to go into DHCP server which is a single threaded application. However
for de-bugging I can have them in my current shell-script.


On Thu, May 14, 2009 at 10:49 PM, Colin Walters <walters at verbum.org> wrote:

> On Thu, May 14, 2009 at 1:07 PM, Abhijeet Kumar Sinha
> <abhijeet.aks at gmail.com> wrote:
> >
> > dbus_connection_read_write(conn,0);
> > msg = dbus_connection_pop_message(conn);
> > if ( NULL == msg ){
> >         usleep(1000);
> >        continue;
> > }
> > I re-wrote the code using glib, to use the glib mainloop.
>
> I wanted to reply to your earlier message to this effect - I'm not
> sure that loop is correct, though it needs analysis.  Basically, using
> DBus not with a mainloop is tricky and not as well tested.
>
> > random_dbus_signal.sh -- is the client side script which sleeps for
> random
> > seconds and then wake up and calls a method of the server -- uses
> dbus-send
> > --system --type=method_call
>
> Unfortunately, there is definitely a DBus bug here.  You need to use
> --print-reply.  See discussion here:
>
> http://lists.freedesktop.org/archives/dbus/2009-March/011054.html
>



-- 
Regards,
Abhijeet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20090514/f818b278/attachment.html