GOAWAY frame can overtake final DATA frame

[edsko]

(This is the corrected issue from #86 ).

I was getting non-deterministic test failures in my test suite. I think it's because when the client sends the final message to the server and then disconnects, there is a race condition between the final DATA frame and the GOAWAY frame. Successful test run:

(The client is sending the value "4" before disconnecting).

Failing test run:

This is the exact same test, but the frame ordering has been reversed: since the server sees the GOAWAY frame first, it never receives the client's final message.

Possibly related: #78.

I am currently using a (rather nasty) workaround by having a threadDelay 1_000 before closing the connection and after sending the final message.

[kazu-yamamoto]

We should ensure that all threads for streaming (spawned with forkManaged) are finished after x <- client $ ... and before let frame = goawayFrame.
An easy way to implement this is provide an STM counter and check (cnt == 0).

[kazu-yamamoto]

Goaway data should hold MVar and the client should takeMVar after putting it into the queue.
Sender should putMVar after sending.
I will take care of this next week.
Have a good weekend.

[edsko]

Fantastic, thanks @kazu-yamamoto :) I can check after ICFP if your patch fixes my test cases.