Reentrancy (Was: RFC: DBUS & KDE 4)

[Waldo Bastian]

On Sunday 03 October 2004 01:59, Havoc Pennington wrote:
> > Well, again, it would help if the D-Bus spec specified a lot of the more
> > complex stuff involved, wrt to blocking/non-blocking call semantics
> > but consider this situation:
> >
> > 1. You're a program you make an outgoing call.
> > 2. You get an incoming call
> >
> > so what do you do? Well, you could handle it. But that can cause unwanted
> > reentrancy. Or you could defer the call until the outgoing call finishes.
> > But that can cause deadlock.
>
> FWIW this is one of the core reasons GNOME is interested in D-BUS,
> because Bonobo did the uncontrolled reentrancy thing which is a Bad Idea
> (tm).
>
> The current answer (for libdbus, this isn't something the protocol
> requires one way or the other):
>
>  - reentrancy is never done implicitly. i.e. when you block,
>    libdbus will never run the main loop. You could write a binding
>    that blocked in the main loop, but I don't suggest it. libdbus
>    will always block without doing other stuff while blocking.
>
>    The point is, if I make something that looks like a method call
>    it shouldn't incidentally run all kinds of unrelated callbacks.
>    Deadlocks are way more reproduceable and manageable bugs
>    than random race conditions where if event A happens during
>    outgoing call B stuff blows up.
>
>    Note that a dbus deadlock only deadlocks the involved apps, not
>    the daemon or other apps.
>
>  - To fix deadlocks, you can do explicit reentrancy in two ways:
>    - write explicitly async code using the main loop and callbacks,
>      sort of like QSocketNotifier or g_io_add_watch() or whatever
>    - use threads, since libdbus is designed to be thread safe
>
>    In those two cases, you are writing the code with explicit
>    reentrancy expectations and have tools such as mutexes to
>    avoid reentrancy bugs.
>
> In doc/TODO is some discussion of doing the "tracking a call stack"
> trick Waldo described and that's a welcome direction that would add a
> third tool for fixing deadlocks, or a way to fix most of them by
> default.
>
> Finally, all dbus calls time out eventually, though the timeout can be
> sort of long to ensure reliability.
>
> Thoughts on the right approach here are very welcome.

For DCOP compatibility we will need to have the automatic deadlock prevention 
available that is currently part of DCOP.

Technically, explicitly marking the reentrancy behavior for remote calls 
sounds like a good solution since you will never get unexpected reentrancy 
this way. On the other hand, if your application isn't designed with 
reentrancy in mind, you will have replaced it with unexpected deadlock, so 
it's a bit a "pick your poison" situation.

I guess the whole question is mostly restricted to the service-provider 
itself. It's in the first place an internal implementation choice, although 
for the automatic deadlock to work, the call stack tracing should be part of 
the protocol and supported by all clients, regardless of the question whether 
it is actually used or not. (So it's important to have this in before DBUS 
1.0)

I would recommend to have the automatic deadlock prevention the default (for 
IDL generated stubs) with an option to explicitly specify one of the other 
two behaviors. Not sure how you would specify that when generating the stub, 
since it's not a property of the interface itself, so it doesn't belong in 
the IDL, maybe it's enough if you have some command line option to your 
stub-code-generator that says "make them all reentrant/non-reentrant".

The nice thing about the automatic deadlock prevention is that you can still 
use it to detect deadlocks when you don't allow reentrancy. In that case you 
can use it to let the incoming call fail and log the problem somewhere.

Note that a special case of this whole reentrancy problem is when you do calls 
to your own client. If you don't allow reentrancy you would always deadlock 
on that in the non-threaded case. (It's not really a special case in the 
sense that it requires a different solution, it's special in the sense that 
it is by definition a circular call)

Cheers,
Waldo
-- 
bastian at kde.org  |  Wanted: Talented KDE developer  |  bastian at suse.com
  http://www.suse.de/de/company/suse/jobs/suse_pbu/developer_kde.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041003/bdbba5ef/attachment.sig>