[Larceny-users] Synch To Latest Larceny SVN Updates - Success

[Ray Racine]

I just re-synch'd to the latest Larceny SVN trunk which included numerous
fixes from PLT's R6RS test suite, multiple R6RS library paths etc. Happy to
report no problems after re-compiling RL3 and running the website.

At this point, I'm vanilla Larceny except for the SIGPIPE signal patch I
added. This is the small change I did to disable the SIGPIPE interrupt.
Opting to ignore the SIGPIPE was originally done for expediency as opposed
to having a handler installed, such as is done for FPE.

However, I'm wondering since the SIGPIPE signal is happening in the socket
code and given that the EPIPE error number is returned and therefore
available, it might be better in the long run to continue to ignore the
SIGPIPE and handle the EPIPE directly by cleaning up the socket fd inside
the socket port read/write code. After ensuring a proper clean up of
resources then one could always raise an exception in the socket port code,
though I am not raising an such an exception currently. Anyway, just
mussing aload.

[***@bpel trunk]$ git diff HEAD larceny
diff --git a/trunk/larceny_src/src/Rts/Sys/signals.c
b/trunk/larceny_src/src/Rts/Sys/signals.c
index dc81e52..bb4a752 100644
--- a/trunk/larceny_src/src/Rts/Sys/signals.c
+++ b/trunk/larceny_src/src/Rts/Sys/signals.c
@@ -152,9 +152,6 @@ void setup_signal_handlers( void )

act.sa_handler = fpehandler;
sigaction( SIGFPE, &act, (struct sigaction*)0 );
-
- act.sa_handler = SIG_IGN;
- sigaction( SIGPIPE, &act, (struct sigaction*)0 );
#elif defined(WIN32_SIGNALS)
SetConsoleCtrlHandler(win32_inthandler,TRUE);
signal(SIGFPE, fpehandler);

[Jed Davis]

Post by Ray Racine
However, I'm wondering since the SIGPIPE signal is happening in the
socket code and given that the EPIPE error number is returned and
therefore available, it might be better in the long run to continue to
ignore the SIGPIPE and handle the EPIPE directly by cleaning up the
socket fd inside the socket port read/write code.

Somewhere I have a half-written message from the last time this came up,
opining that there's not much point to SIGPIPE if you're checking the
return from write() and friends.

That is, my understanding of SIGPIPE is that it's at best a convenience
feature for pipeline filters (or one-shot network things) written in C
(or other language without some sort of exception mechanism), where you
always want to exit when the pipe/socket goes away.

(Also, SIG_IGN is not quite the same thing as an empty signal handler
function, but the difference is not observable here.)