Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Matthew Mondor <mm_lists-xHKImXiT534xnpGSZB1jBA <at> public.gmane.org>
Subject: Re: EPIPE and C errors
Newsgroups: gmane.lisp.ecl.general
Date: Tuesday 2nd October 2012 22:54:51 UTC (over 4 years ago)
On Tue, 2 Oct 2012 23:32:57 +0200
Juan Jose Garcia-Ripoll
<[email protected]> wrote:

> On Tue, Oct 2, 2012 at 11:24 PM, Matthew Mondor
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 :)

Thanks,
-- 
Matt

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
 
CD: 4ms