zrpc smac handle_read issue.

[Bug Importer]

I've been extending ZEO to allow RPC calls on ZEO objects. In the process I've had to work around what I would consider to be a bug in zrpc. In the zrpc.smac.SizedMessageAsyncConnection.handle_read there is a lock, around the call to message_input() which is where the processing of zrpc call takes place.

This operation of this lock is described as follows:
# XXX We call message_input() with __input_lock
# held!!! And message_input() may end up calling
# message_output(), which has its own lock. But
# message_output() cannot call message_input(), so
# the locking order is always consistent, which
# prevents deadlock. Also, message_input() may
# take a long time, because it can cause an
# incoming call to be handled. During all this
# time, the __input_lock is held. That's a good
# thing, because it serializes incoming calls.

Unfortunately, an effect of the serialisation that it will then block all calls back into the connection. If an rpc call happens to call back to the otherside of the connection then a lockup will occur because the first handle_read still holds the lock when a second handle_read call is initiated for the reply for the call to the otherside.

Right, I hope that makes sense.

[Timothy McLennan (timmcl)]

Sorry, that bug got entered from an anonymous user. I've now created one.

[Tim Peters (tim-one)]

Changes: classification (bug => feature), new comment

I changed this to a feature request. The locking done by ZEO is critical to its correct operation, and so long it works for ZEO's own purposes it can't be called "a bug".

That said, for the same reason it's unlikely anyone at Zope Corp devote work time to this, in which case any change you think is needed will have to come from an interested volunteer.

[Hanno Schlichting (hannosch)]

This looks like a rather obscure feature request which hasn't seen any other support in years.