This reminded me of another similar case that puzzled me some time ago
when I began using ECL, and that one was handled in the line reader.
LINE-READ still had a case to remap a simple-error to an
sb-bsd-sockets:operation-timeout-error. This condition happens when an
input timeout is set via setsockopt(2) and the input timeout elapses
(read(2) then errors with EAGAIN). This is another case where I now
see SI::SIMPLE-STREAM-ERRORs reported instead (the catch for
SIMPLE-ERROR (a parent/superclass I assume) still matches, but I just
changed it to catch STREAM-ERROR instead as well).
Unfortunately there's still no way to differenciate a timeout error
(EAGAIN) from a broken pipe one (EPIPE) when using STREAM-ERROR.
However, because of the design of the system (in HTTP we first read a
request then answer, so it's not highly bidirectional, and blocking
mode is used with threads in this case to allow CPU-bound applications,
so EAGAIN/EWOULDBLOCK will not occur for output). As a result, EPIPE
will only occur for output (treated like end-of-file) and EAGAIN for
input (treated like input timeout), so in this case the problem is
solved for now.
If I need advanced unblocking I/O and polling in the future, I'm
unlikely to rely on the native sb-compatible sockets support, and that
system will have to export errno. There's always libIO+CFFI, and
perhaps eventually my ressuciated ecl-unix on top of mmffi (no
time-line on that though, it's only a hobby :)