[Larceny-users] Larceny Runtime - SIGPIPE Handled?

[Ray Racine]

On Mon, 2008-05-19 at 09:34 -0400, William D Clinger wrote:
> If you can send us a prototype of the signal-handling
> code you want for one of those, with a fairly simple
> test case, then we should be able to generalize it to
> all five.
> 
> Will

It was the SIGPIPE signal causing Larceny to exit.

On Linux "kill -s 13 <pid>" sends the given process a SIGPIPE.

Given an running instance of Larceny the above command does cause
Larceny to silently exit.

OTOH, "kill -s 8 <pid>" sends a SIGFPE which puts the Larceny process
into the debugger.  

My design goal is to have Larceny ignore the SIGPIPE signal and have the
scheme custom io port socket code deal with the returned EPIPE (32)
error code on a broken connection from the write() call.

Turns out on Linux there exists a pre-canned ignore handler SIG_IGN.  
So the following does the trick.

act.sa_handler = SIG_IGN;
sigaction( SIGPIPE, &act, (struct sigaction*)0 );

In signals.c

==============================================

diff --git a/trunk/larceny_src/src/Rts/Sys/signals.c
b/trunk/larceny_src/src/Rts/Sys/signals.c
index bb4a752..dc81e52 100644
--- a/trunk/larceny_src/src/Rts/Sys/signals.c
+++ b/trunk/larceny_src/src/Rts/Sys/signals.c
@@ -152,6 +152,9 @@ 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);

==============================================

After recompiling Larceny 
kill -s 12 <pid> is, as expected, ignored by Larceny.

My test case is pretty easy on my side, but I'm struggling for a simple
test case for the Larceny developers to test cross O/S.

On my side, I start my Larceny webserver, go to my test home page, and
execute 2 rapid refresh clicks. The browser terminates the first request
on the second click refresh click, causing the SIGPIPE.  This happens
pretty much every time.

With the above change Larceny does not exit, and the socket scheme code
sees the expected EPIPE error code returned from the FFI write() call.

To simulate the problem with standard Larceny and its accompanying
libraries the following test outline should reproduce the problem.

In thread or process #1 open up a server socket.  Upon accepting a
client connection start writing a 1K buffer of data in a loop for say
100 times.  e.g. send 100k of data

In thread or process #2 create a client socket which connects to #1's
server socket.  Read the first a 1K or two of data, then #2 closes the
socket without reading the rest of the data.

#1 should silently exit Larceny to the command line on the SIGPIPE
signal.



Ray