Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upplatform/unix: Don't return ECONNRESET if dedicated channel is closed #148
Conversation
So far, when the sender of a dedicated channel in a large transfer was closed before the receiver got the expected amount of data, `recv()` returned a "channel closed" status, just as if the main channel was closed. This is incorrect though, since the main channel is still open, and the receiver shouldn't be dropped. Returning `EIO` now instead -- which is a bit of an abuse I guess; but probably as good a choice as any, as long as we are sticking with Unix error codes only...
|
@antrik Sure! |
|
To clarify: while it turns out #133 is not affected by this at all, I'm still pretty sure it's more correct this way, and we should commit the change... |
|
r? @danlrobertson |
|
Is this still valid? It seems like a possible scenario, and I did run a test with #149 and this that ran without issues. |
|
It turns out I'm not so sure any more now... The only scenario I can think of where this would get triggered, is when the sender dies unexpectedly before it finishes the send. Since the main channel normally would also get closed in this case, returning Closing for now to avoid confusion. |
antrik commentedFeb 14, 2017
So far, when the sender of a dedicated channel in a large transfer was
closed before the receiver got the expected amount of data,
recv()returned a "channel closed" status, just as if the main channel was
closed. This is incorrect though, since the main channel is still open,
and the receiver shouldn't be dropped.
Returning
EIOnow instead -- which is a bit of an abuse I guess; butprobably as good a choice as any, as long as we are sticking with Unix
error codes only...