python-trio / python-trio/trio
StapledStream.send_eof should error out if you call it while send_all is pending
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 7.3k
- Forks
- 431
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 6
Description
Noticed while working on #823: normally, if you try to call send_eof on an object at the same time that another task is already calling send_all or wait_send_all_might_not_block, then send_eof should raise BusyResourceError. But StapledStream.send_eof calls self.send_stream.aclose, which has a different semantics: it interrupts any pending calls. So right now StapledStream.send_eof has the wrong semantics.
To solve this, StapledStream should detect when another task is already calling a send method, and in that case make send_eof raise an exception instead of calling self.send_stream.aclose.
I have a fix for this in my #823 branch, that I'll post shortly.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the StapledStream implementation and inspect send_eof alongside send_all and wait_send_all_might_not_block. Compare their handling of concurrent sends and the existing BusyResourceError behavior. Done means send_eof reports the busy condition instead of interrupting a pending send.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100