Lockup at client when awaiting JSON body

[japhb]

I have been converting the cro-websocket test files into performance tests of the various pieces. This had been working fine with most of the parser/serializer/handler bits, but when I did a test of the whole client/server pair, I ran into a lockup at the client.

See https://gist.github.com/japhb/c07f5699dbb6d2e45a392865b52abe58 for the test file. (The perf test version of this file just comments out the say calls and raises $repeat to something in the ~1000 range.) It's pretty straightforward; I was comparing the performance of round trips of text and JSON bodies, using a server side taken nearly as-is from t/http-router-websocket.t. The client should be pretty uncontroversial, but though it seems to work fine for plain text round trips, it locks up while awaiting the body-text on the client side for JSON round trips.

Any ideas what's going on here? The only obvious thing I can see different between the plain text and JSON cases with CRO_TRACE=1 is that the plain text response is sent unfragmented, while the JSON response message is sent as a fragment frame containing the entirety of the JSON data followed by an empty continuation frame, but if that's really the problem I'm surprised cro-websocket passes it's own test suite.

[jnthn]

Messages sent on a Supply are processed one at a time, the sender getting back control once the downstream things have processed the message. This provides a backpressure mechanism. I think the await on a fragmented message induces a circular wait: the frame parser doesn't get back control because the message it emitted is not yet processed, but the await can't make progress until the frame parser also does. Probably we need to introduce a little more concurrency somewhere to avoid this.

[japhb]

jnthn: Where are you thinking about adding additional concurrency? I can imagine making changes anywhere from the most specific (hacking additional concurrency specifically in the frame parser / message parser boundary) to the most general (making sure that type of circular wait can't happen in rakudo), and lots of points in between (such as allowing cro pipelines to declare that they do fan-in or fan-out and making sure the pipeline implementation accounts for that).