[Ecls-list] Streams over sockets and SIGPIPE

[Matthew Mondor]

On Mon, 17 Aug 2009 21:29:16 -0400
Matthew Mondor <mm_lists at pulsar-zone.net> wrote:

> On Mon, 17 Aug 2009 21:21:52 -0400
> Matthew Mondor <mm_lists at pulsar-zone.net> wrote:
> 
> > I wonder if it'd be best to install a SIGPIPE handler or to modify the
> > code such that depending on configuration MSG_NOSIGNAL be used.  The
> > advantage of a handler would be the possibility to report a CL
> > END-OF-FILE condition (which SBCL appears to be doing).
> 
> Oh, it's also possible that SBCL signals END-OF-FILE when errno is
> EPIPE after sendto(2) returns -1, and that a handler causes SIGPIPE to
> be ignored, or that it explicitely uses the MSG_NOSIGNAL flag.
> I didn't check yet.

Considering that ECL uses stdio FILE * streams, this limits the
internal low-level implementation which can't portably be defined.  If
there's ever any goal to eventually include a custom implementation of
optionally buffered streams, it's something I could eventually help to
work on, but supporting FILE still has an advantages for embedding (and
should probably be one of the supported layers of a more low-level
streams system)...

Currently this means that using streams over sockets cause fwrite(3) to
be called which internally result in transparent write(2)s on unix
(which cannot be customized).  This also makes using
select(2)/poll(2)/etc harder to discover POLLERR/POLLHUP condition
(discouraged with stdio FILE * internal descriptors and there are
buffering control issues).

It would be possible to only use low level socket library calls with
custom buffering, although that streams can easily be created over
sockets suggests this also should work without too much effort.

If a signal handler was used to catch SIGPIPE, there are complications,
unless it simply is set to SIG_IGN: POSIX-specific, also the signal may
propagate to any thread not blocking the signal, and I fail to see
siginfo(2) information allowing to obtain precise information on the
descriptor for which it occured.  If set to SIG_IGN, write(2) should
fail with EPIPE, and fwrite(3) should in theory return a short write
count, which should be considered as an error (a generic stream-error
would probably then be signaled)?  I should try setting SIG_IGN for
SIGPIPE in my test code and see what happens.

As for Windows I have no idea if a similar problem exists or not, and
how to fix it if so.

Thanks,
-- 
Matt