You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both ServerFlow and ClientFlow are implemented with the strategy "send before receive" (see #88 for rationale). This might result in a deadlock once the send buffers are full because neither server nor client will try to receive any bytes from the other side.
I think we can solve this by giving up the strategy "send before receive". Instead we use a select! inside the implementation of ServerFlow and ClientFlow that allows us to send and receive in parallel. However, there might be some invariants in the current implementation that expect sending to be completed before receiving is started. I expect most of them inside of send_command.rs.
This is also something we could test programmatically with flow-test.
The text was updated successfully, but these errors were encountered:
Both
ServerFlow
andClientFlow
are implemented with the strategy "send before receive" (see #88 for rationale). This might result in a deadlock once the send buffers are full because neither server nor client will try to receive any bytes from the other side.I think we can solve this by giving up the strategy "send before receive". Instead we use a
select!
inside the implementation ofServerFlow
andClientFlow
that allows us to send and receive in parallel. However, there might be some invariants in the current implementation that expect sending to be completed before receiving is started. I expect most of them inside ofsend_command.rs
.This is also something we could test programmatically with
flow-test
.The text was updated successfully, but these errors were encountered: