Reporting here, as cryptonomex/fc does not track issues and I assume no one cares about bytemaster/fc anymore.
Calling write on a fc::tcp_socket which has reached EOF on a previous read may work, or it may hang forever (I find that it will always hang forever if enough bytes are written or write is called multiple times). Writing to a TCP socket when the remote end has shutdown writes is explicitly legal under TCP semantics, so this should either work or throw.
Note that it is apparently impossible to handle this gracefully as FC's normal timeout mechanisms fail in this instance as well. I attempted something similar to the following:
if (haveReadEof) {
fc::async(socket.write(...)).wait(fc::milliseconds(100));
} else {
socket.write(...);
}
This also did not work, as the call to wait(fc::milliseconds(100)) hangs forever when socket.write hangs forever, instead of throwing fc::timeout_exception as it should. My workaround is simply to throw if an EOF has been read, without trying to write.
Reporting here, as cryptonomex/fc does not track issues and I assume no one cares about bytemaster/fc anymore.
Calling
write
on afc::tcp_socket
which has reached EOF on a previousread
may work, or it may hang forever (I find that it will always hang forever if enough bytes are written or write is called multiple times). Writing to a TCP socket when the remote end has shutdown writes is explicitly legal under TCP semantics, so this should either work or throw.Note that it is apparently impossible to handle this gracefully as FC's normal timeout mechanisms fail in this instance as well. I attempted something similar to the following:
This also did not work, as the call to
wait(fc::milliseconds(100))
hangs forever whensocket.write
hangs forever, instead of throwingfc::timeout_exception
as it should. My workaround is simply to throw if an EOF has been read, without trying to write.