implementing IN_PROGRESS

[Havoc Pennington]

Hi,

On Sat, 2006-02-25 at 23:06 +0100, Thiago Macieira wrote:
>      calls dbus_connection_dispatch (TAKES DISPATCH LOCK)
>        acquire locks
>        for each message in connection queue:

I see. This is the key - right now dbus_connection_dispatch() will never
dispatch more than one message. One reason is to keep the main loop
relatively "fair" (avoid e.g. locking up the GUI while we drain a long
message queue or something). GLib main loop also handles only one X
event per iteration, etc. Probably the larger reason is just that it
makes the code easier for me to think about ;-)

Anyway, that's why I didn't understand what you meant, I was assuming 1
message per dispatch.

> If I understand your solution correctly, it won't solve my problem. The 
> reason the main loop is reentered is because we *want* to handle a new 
> message.
> 
> The concrete example of what my user is doing is:
> - connects signal from Hal to his application
> - in his signal handler, he makes a *blocking* call to Hal again

Right. In my "IN_PROGRESS" proposal the way this would have to work is
that the blocking call would not run the main loop, it would just block
on the dbus socket until the reply message arrived. It would not
dispatch any messages _except_ the reply to the blocking call. This is
working right now because _dbus_connection_block_pending_call() does not
take the dispatch lock, though as I noted that seems somewhat unsafe.

However, I think I'm dumping the "IN_PROGRESS" proposal and now
proposing that we just make the dispatch lock recursive, which I
hope^H^H^Hthink solves everything. Do you see anything it won't address?

The only downside I see is that adding a recursive locks requirement to
DBusThreadFunctions will require changes to all bindings that provide a
thread implementation.

Havoc