[Ecls-list] EPIPE and C errors

Matthew Mondor mm_lists at pulsar-zone.net
Tue Oct 2 22:54:51 UTC 2012

On Tue, 2 Oct 2012 23:32:57 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> On Tue, Oct 2, 2012 at 11:24 PM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:
> > The httpd currently matches it fine using (or end-of-file
> > si::simple-stream-error)
> Use STREAM-ERROR instead. It is more portable. The SI::SIMPLE- ... is a
> problem due to the fact that standard conditions do not have detailed
> explanations attached and should not be used in your code (I can change the
> package, though).

Thanks again, that works.

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 :)


More information about the ecl-devel mailing list