implementing IN_PROGRESS

[Havoc Pennington]

On Sun, 2006-02-26 at 00:55 +0100, Thiago Macieira wrote:
> The point is that the message filter is called while the dispatch lock is 
> held. Since I can't recurse under those conditions, I can't call to user 
> code. On the other hand, the library cannot make the call with an 
> unlocked dispatch because the connection could change under its feet. It 
> can't know, before calling the binding code, if it will be handled or not 
> or if it'll be handled by the message filter or by the object tree 
> callback. Or, if I understand the code correctly, by *which* binding 
> using that connection.
> 
> The solution I am proposing is to give the binding a chance to say "yes, I 
> want to handle this message, but I can't right now because the lock is 
> held; call me again once you release the lock".

I think I get it now, I'm sorry I'm a little slow. Your proposal lets us
hold the dispatch lock while fully determining which handlers/filters
will be called; right now we need to call app handlers while this is
still being determined, since we only get HANDLED or NOT_YET_HANDLED
_after_ the app handler runs.  Thus app handlers have to be inside the
dispatch lock, to make the entire processing of the current message run
atomically without mixing in a pop() or another dispatch on the same or
subsequent message.

In your proposal dbus_connection_dispatch() can fully complete the
dispatch process (trying all the filters/handlers), finding the handler
that will be used; then unlock, and call that handler again.

There are several ways I can think of that a handler would know it's
being called the first time or the second time; any thoughts on that?

dbus_bool_t dbus_connection_get_in_dispatch(DBusConnection*)
is one idea, but on the other hand this state is thread-specific so this
function is tough to implement ...

In DBusObjectPathVTable we could put another function to be used the
second time, but that won't work for message filters, only for
registered object path handlers...

> >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?
> 
> I'm more afraid of the side-effects this could bring. If the lock is 
> recursive, the bindings (plural!) are allowed to change the connection 
> under the dbus_connection_dispatch's feet. So I'd rather go for the 
> solution with the minimal impact, if it solves the same problem.

Yeah. With a recursive lock I guess I'm hand-waving some tough issues
about reentrancy within the same thread, and your approach would avoid
those by still requiring apps to avoid recursive dispatching.

Havoc