socket multiplexing (deadlocks!)

[Havoc Pennington]

On Tue, 2004-09-07 at 13:51 -0400, Jim Gettys wrote:
> It is more than just multiplexing.
> 
> There are subtle deadlock problems that can take place, which
> require some sort of a flow control system to solve.
> 
> See the discussion "Deadlock Scenario" in
> 
> http://www.w3.org/TR/1998/WD-mux-19980710
> 
> Right now, dbus, in some usages, can deadlock entirely, I believe.

I guess there's one case now where we effectively block and could
deadlock, which is when buffering the message itself and we don't have
enough memory to read the message. So effectively right now clients must
have the max message size available in memory. The max message size is
arbitrarily 32M in the current code. We could make this max message size
dynamically negotiated, but to avoid the deadlock 100% for sure each
process would need to preallocate the max-sized message buffer and never
free it, I think... that might suck. Kind of a nasty tradeoff to make
the max size large and eat tons of RAM, or make the max size low and be
hitting the max all the time.

We could just have VM systems always set a huge max message size, and
not preallocate it, and assume memory won't be exhausted (as the whole
desktop already does); but still negotiate max message size so some
embedded device could set it low. Then we'd have attempts to send too-
large messages just fail with an error.

I'm not sure there's a problem with the current protocol though, because
the message length is in the message header, and you could just send an
error for a too-large message and then drop the bits on the floor
instead of reading them. The problem may just be with the current
implementation of the library, which will never dump a message on the
floor in this way.

Once we're dealing in whole messages instead of the byte stream, dbus
will always return errors instead of blocking, so should not deadlock on
that level. Of course, one of the motivations for looking at
multiplexing is to make it more reasonable to block instead of returning
the errors. In that case a deadlock is still possible but would be more
limited in scope since streams of messages would belong to say
particular objects or code modules rather than to entire processes.

Not sure this is all right, but those are my general thoughts at the
moment.

Havoc