Repository navigation
send should check socket status and fail if the socket is closed #169
Description
Activity
Bump.
Will you accept a PR fixing the code to match the documentations? Note that is will add one
withMVarpersendandrecv, also it will serialize sending and receiving.Alternatively will you accept a PR fixing the documentation to match the implementation?
Please submit the PR and we can discuss the cost and benefit. Checking seems like the right thing to do.
@eborden Thank you for your response!
Which PR should I send? The one that fixes the code or that fixes documentation?
I don't think
withMVarreally makes sense here. @Peaker suggested read/write lock, but it is out of my abilities because it is too intrusive and I can't test all CPP configurations.Checking socket status without locking can help to make the issue more visible, though it will not really fix. I think that fixing documentation is the first step.
- added a commit that references this issue
on Feb 7, 2016 I'd prefer the bug fix over a doc fix. A naive implementation using an mvar can get the ball rolling and we can refine from there. Likely the read/write lock is the final destination, but high level code can suss out some details first. Thanks for being persistent with this issue.
- added a commit that references this issue
on Feb 7, 2016 I discussed this with my friend.
- This bug is serious and should be fixed somehow.
- I don't want to modify the current API. The pull request introduces significant overhead. I would avoid this way.
- So, let's create
Safemodule.sendand other APIs inSafemodule checks the socket status.
What do you think, guys?
Reacted by Evan Rutledge Borden and 日比野 啓 (Kei Hibino)It is definitely better then doing nothing. And the documentation for the old API should be updated to describe the issue and point to
Safemodule.- added a commit that references this issue
on Jun 15, 2016 I'm working on a PR with a
Network.Socket.Safemodule, along withNetwork.Socket.ByteString.SafeandNetwork.Socket.ByteString.Lazy.Safe.- added 3 commits that reference this issue
on Jul 16, 2016 - added a commit that references this issue
on Jul 26, 2016 I close this in favor of #212.
The
Network.Socket.closeclaims thatIt changes socket state to
Closedand callsclose(2)C function, so OS is free to reuse the FD.But
Network.Socket.sendand friends don't check socket status. When sending data to a closed socket usually an exception is thrown (close(2)returnsEBADF), but there is a chance that the FD is reused afterclosebut beforesend, so the data will be silently sent to a wrong destination.One can argue that writing to a closed socket is a bad practice anyway, then please consider it as a documentation bug.