[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.

[ray at 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);
-------------- next part --------------
HTML attachment scrubbed and removed