dbus_connection_send_with_reply_and_block and unrelated messages

[Havoc Pennington]

William Lachance wrote:
> On 5/29/06, Kevin Krammer <kevin.krammer at gmx.at> wrote:
>> On Sunday 28 May 2006 15:22, Thiago Macieira wrote:
>>
>> > The reason I'm asking is that I'm making a call to
>> > org.freedesktop.DBus.RequestName. Before the reply comes in, we get two
>> > signals. This means those two signals will be in the dispatcher queue.
>> > But the Qt bindings won't see them until there's activity again in the
>> > D-BUS socket.
>>
>> Another scenario is when you start an async call followed by a sync call
>> without returing to the eventloop inbetween.
> 
> This reminds me of something I've been wondering about: is there any
> reason why dbus can't provide an async version of
> dbus_bus_request_name? Such a method would be useful to those of us
> who want to provide a high-level API which is purely non-blocking..

request_name is just a convenience function that probably shouldn't 
exist to begin with - if you're providing a high-level API I would not 
even wrap request_name (or the other method-calling things in 
dbus-bus.h), I would just call the request name method in the normal way 
you would call a method in your high-level API.

Havoc