Enable command pipelining

[Davidde94]

Resolves #528

Previously the user wasn't able to write a command while another was waiting for continuations. This isn't very friendly, and isn't great In any real-world scenario. Now we queue commands, and as soon as all continuations for one command have been handled, we move on to the next.

[weissi]

Unfortunately, this won't work for certain cases. We should probably fix this or at the very least detect them and crash (and file an issue).

[weissi]

Left a few comments, there are certainly a few new re-entrancy bugs here. And I don't think we have a write re-entrancy test case.

[weissi]

isn't there a lot of logic duplicated here from above?

[Davidde94]

Yeh this was already here but I can factor it out

[weissi]

Yes please

[Davidde94]

@weissi I've filed an issue so we don't forget about the re-entrancy issues : #555

[weissi]

I think this isn't right. I think if this context.write fails here, we'll never fail the user promise (and will therefore crash). If the user gave us a promise, you'll need to .cascadeFailure into the user's promise.

[weissi]

& test please

[Davidde94]

The code didn't change here again, but I can add the cascade

[weissi]

Yes please

[weissi]

is that the one you want to fix in a separate issue? Happy with that as an exception

[Davidde94]

Yep!

[weissi]

So I can't really claim I fully understand this code anymore. The interaction between self._bufferedCommands, self.currentEncodeBuffer, and the state machine bits that are inline with the channel handler code is very complex. Also we already know of one bug (I think) which is hit by the commented test.

But I think we can get this in to unblock folks assuming the deficiencies are properly filed in issues. I'd recommend refactoring this in two bits:

1. state machine which does all the state handling and returns an "action"
2. the channel handler implementation which just drives the state machine and calls out to the others via the channel pipeline.

This will then also allow testing the state machine without setting up channels, channel handlers etc.

[danieleggert]

So I can't really claim I fully understand this code anymore. The interaction between self._bufferedCommands, self.currentEncodeBuffer, and the state machine bits that are inline with the channel handler code is very complex. Also we already know of one bug (I think) which is hit by the commented test.

But I think we can get this in to unblock folks assuming the deficiencies are properly filed in issues. I'd recommend refactoring this in two bits:

1. state machine which does all the state handling and returns an "action"
2. the channel handler implementation which just drives the state machine and calls out to the others via the channel pipeline.

This will then also allow testing the state machine without setting up channels, channel handlers etc.

@Davidde94 Are you tracking this refactoring in another issue?