Guarantee atomicity of WINDOW_UPDATE increments.

[lucasdicioccio]

The current code may lead to over-estimating the window size.
The over-estimation occurs as follows:

• the initial window state is W
• the receiver observes a window update and computes W+K in a first
  transaction
• the sender decrease the window by the payload size P, hence the window
  state is set to W-P
• the receiver writes W+K in the second transaction

This over-estimation carries over and may lead to unexpected GOAWAYs.

[lucasdicioccio]

For the record, I've been hammering a warp-tls-enabled toy server with my temptative HTTP2 client at https://github.com/lucasdicioccio/http2-client .

If you want a repro case, use the exe in the above link and use this for server:

server :: IO ()
server =
    runTLS defaultTlsSettings (Warp.setLogger (\r s n -> print r) $ Warp.defaultSettings) app
  where
    app req f = f $ responseBuilder status200 [ ("Content-Type", "text/plain")
                                              , ("Content-Length", "5")
                                              ] $ copyByteString "HELLO"

[kazu-yamamoto]

LGTM. But I have a comment.

[kazu-yamamoto]

Why don't you use modifyTVar'?

[lucasdicioccio]

Last time I checked (and I was sad) TVar.modifyTVar returns unit, unlike modifyIORef.

As per the strictness, the strict pattern binding '!w' will evaluate the thunk.

[kazu-yamamoto]

Last time I checked (and I was sad) TVar.modifyTVar returns unit, unlike modifyIORef.

You are right. This is my fault. Never mind.

As per the strictness, the strict pattern binding '!w' will evaluate the thunk.

Yes. Please do so.

[lucasdicioccio]

No worries :-).
For the point about strictness, I think the bang pattern at the output of the atomically call in my current patch is enough. It's true I could seq the thunk from within the STM. I believe it does not matter much performance-wise here: either concurrent threads will wait more in the STM or evaluating the thunk themselves. But if I'm wrong I'll be happy to learn something :-) (maybe I overlooked some bit about the senders).

[kazu-yamamoto]

I worry about space leak. If you don't have a strong reason to use lazy evaluation, I would recommend the bang pattern.

[lucasdicioccio]

Ack. I've added a strictness annotation from within the STM (cf. a48c7aa.) In that particular instance since w1 was returned and immediately evaluated by the bang pattern I guess it was fine.

I can rebase on master and squash if you prefer a clean history. Let me know.
Thanks for the review!

[kazu-yamamoto]

No need for squash but rebase is great.

[lucasdicioccio]

Thanks. I've rebased (and made the commit message more precise for the 2nd commit).

[kazu-yamamoto]

Very good.

[kazu-yamamoto]

Merged. Thank you for your contribution!