Re: Deadlocking in the transport

[Willy Tarreau <[e-mail]>]

Hi Martin,

On Wed, Jan 10, 2018 at 05:17:14PM +1100, Martin Thomson wrote:
> 4. Block the problem at the source.  It was suggested that in cases
> where there is a potential dependency, then it can't be a problem if
> the transport refused to accept data that it didn't have flow control
> credit for.  Writes to the transport would consume flow control credit
> immediately.  That way applications would only be able to write X if
> there was a chance that it would be delivered.  Applications that have
> ordering requirements can ensure that Y is written after X is accepted
> by the transport and thereby avoid the deadlock.  Writes might block
> rather than fail, if the API wasn't into the whole non-blocking I/O
> thing.  The transport might still have to buffer X for other reasons,
> like congestion control, but it can guarantee that flow control isn't
> going to block delivery.
> 
> 
> ## My Preference
> 
> Right now, I'm inclined toward option 4.

Well, I'm lagging a bit too much to have a valuable opinion, but all
I can say is that from a protocol design perspective, this option
totally makes sense. Starting to send when you depend on something
which is blocked doesn't make real sense. In fact it could even be
argued that in such dependencies cases, the flow control could be
shared, i.e. Y could offer some of its budget to X to ensure it can
make progress resulting in the two ultimately being unblocked. I know
it would imply a number of painful changes though and I'm just talking
about threory here.

Regards,
Willy