Dbus multiple threading problem

[Vinoth V]

Hi..

I created the thread concept and enabled the dbus working :)

now i am doing the dbus bench marking. finding the latency and average of
each thread across dbus.

Initially i used to get 4.3msec as the average time to call a function in
dbus(i.e  calling a function in server and getting a return value for  the
called function),
but later now i am getting 24.3msecs as the average time to call a same
function.I didnt do any change to the function which is being called.

so i am  thinking is there anything i am missing, do the dbus message bus
need to flushed or is there anything like that need to be done across the
dbus.
 to make the dbus to work faster and maintaine its transfer speed.


Thank you.

vinoth



On Tue, May 22, 2012 at 4:26 PM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:

> (Please ask the mailing list rather than asking individual contributors.
> If you ask me personally, only I can help you, and if I'm too busy, you
> won't get an answer; if you ask the mailing list, anyone on the list can
> help you.)
>
> On 22/05/12 11:38, Vinoth V wrote:
> > but  I have requirement like message need to pass from server to client
> > also.
>
> That's possible.
>
> > for every 2 mins server will send a specific details to its client, this
> > msg should be initiated by the server and client should respond back...
>
> That's possible. I'd do this as an asynchronous method call sent by the
> "server" to the "client". This reverses their usual roles, but that's OK
> - all processes on D-Bus are treated the same. Telepathy and BlueZ both
> have situations where the process you'd normally think of as the
> "server" calls methods on the process you'd normally think of as the
> "client".
>
> It has to be an asynchronous method call (send request, go back to your
> main loop, get a callback called from your main loop later) because if
> two processes try to make synchronous method calls to each other,
> they'll typically deadlock while each waits for the other to reply.
>
> You should make asynchronous method calls anyway, though; see
> <http://smcv.pseudorandom.co.uk/2008/11/nonblocking/>.
>
> > Is there any API avaliable in glib to do this or we need to create a
> > another message bus for the client side to meet my requirement.
>
> Export an object with a method from the "client" (e.g. with
> g_dbus_connection_register_object()); make the "client" tell the
> "server" its unique name somehow (e.g. call
> g_dbus_connection_get_unique_name() and send that to the "server"); make
> the "server" call the client's method by using that unique name.
>
> > whether my requirement can be  achieved using signals ..?
>
> You could do this with signals too, although method calls would probably
> be easier to understand:
>
> * emit signal with your "specific details" every 2 minutes
> * your client responds to that signal by calling a method on the server
>
> > but i need to
> > send data structures as arguments ..
> > maximum  three arugments i need to send from the server to client.
>
> You can send nearly any data structure that you can encode into a
> GVariant (exceptions: you can't send any type involving "maybe", you can
> only send a dict-entry if it's in an array of dict-entry, and you can't
> send empty tuples).
>
> If you have a complex data structure you will need to work out how to
> encode it as a D-Bus message (or, equivalently, as a GVariant without
> using the features I mentioned).
>
>    S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20120529/f3bb610d/attachment.htm>