Thanks Simon. It worked great. As I said, my client emits 'req' signal and server processes it. In my system, there would be multiple clients emitting same signal 'req', which server in turn needs to process. Would such type of many to one association, overload DBUS? If yes, would such problem get resolved if every client emits different signal (ex. client1 emits req1, client2 emits req2 etc) for server? Thanks again. <div class="gmail_quote">On Wed, Aug 29, 2012 at 6:13 PM, Simon McVittie <<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank">simon.mcvittie@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On 29/08/12 13:18, rajnikant jachak wrote: > But client dumping > core (Abort Signal) while receiving the responses. </div>Your client is multi-threaded, but does not call dbus_threads_init_default(). That isn't expected to work. <div class="im"> > 2. Is it recommended to use DBUS library in multi-threading applications? </div>No. In theory it's meant to work (if you call dbus_threads_init_default() before calling any D-Bus APIs or starting your second thread), but you have to be really careful, and restricting your use of D-Bus to one thread results in more predictable behaviour. Alternatively, use GDBus (in GIO, part of GLib) which was designed with multi-threading in mind. S </blockquote></div> -- Regards, Rajnikant Jachak. The pessimist sees difficulty in every opportunity. The optimist sees the opportunity in every difficulty.