proof of concept for deterministic close race

[belm0]

No description provided.

[coveralls]

Pull Request Test Coverage Report for Build 21

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 92.048%

---

Totals
Change from base Build 19:	0.3%
Covered Lines:	382
Relevant Lines:	415

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 31

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.8%) to 92.754%

---

Totals
Change from base Build 27:	0.8%
Covered Lines:	384
Relevant Lines:	414

---

💛 - Coveralls

[belm0]

the checkpoint could be eliminated in the common case at the cost of more complexity

def __init__():
   ...
   self._for_testing_peer_closed_connection = None

...

if self._for_testing_peer_closed_connection:
    self._for_testing_peer_closed_connection.set()
    await trio.sleep(0)

[mehaase]

This is an interesting concept, but I wonder if this one execution path deserves special handling? There are other execution paths that race, too. I think I would rather rewrite some of the race-prone code now that I better understand some of the issues involving the reader task (e.g. #90), and then maybe have some kind of connection fuzzing script (a generalization of issue_96.py). Thoughts?

[belm0]

Placing synchronization hooks at strategic points to induce known race scenarios has the advantage of supporting deterministic test cases. The fuzzing tests can get costly due to combinatorics and required resolution, and seem more appropriate as an offline tool to discover the races.