There is an issue for pending calls taking very long until getting processed.  As there are many applications using pending calls for asynchronous IPC via D-BUS this will definitly hit us.  An easy example is starting hal-device-manger.  It takes several seconds to pop up.

I expect other (so far) unaccountable delays I have seen to be solved by getting rid of this bug.

Quote from J5 on the D-BUS list:

> I had a eureka moment and finally distilled the python introspect
> problem down to a simple C test case.  This is the cause of
> hal-device-manager taking ages to start up but I am not sure what the
> fix would be.
> 
> Basically it happens when you create two pending calls and then block on
> the one that you sent last.  My best guess is that the second pending
> call is starving the data from the socket without actually processing
> any of the data it doesn't care about.  When be block on the first
> pending call there is no data to read over the socket so it blocks for
> its specified timeout in poll.  When it times out the data is processed
> and the correct things happen.  Hopefully now that the problem is
> identified we can find a solution and package this as part of the test
> suite.