ANNOUNCE: GHC 6.10.2 Release Candidate 1

[Simon Marlow]

> I've tried the 6.10.2 RC with some performance-sensitive work code.
> The code uses the non-threaded runtime, and makes extensive use of
> signals. The results look very good.
>
> The slightly funny (but useful to us) benchmark measures bandwidth
> communicating between multiple unix processes. Here's a graph of how
> much better 6.10.2 is doing:
>
>     http://galois.com/~dons/images/bandwidth.png
>
> Note we're over a 1G/s bandwidth now with 6.10.2 for the first time :)
> Thanks guys!
>
> (Note also we use a slightly modified runtime that has thread deadlock
> detection disabled).
>
> There have been quite a few runtime patches, enough that 6.10.2 is
> really quite a different runtime now:
>
>     http://galois.com/~dons/rts.patches
>     http://galois.com/~dons/6101-6102.diff
>
> Anyway, all those signal and thread handling changes are looking good.

Looking back through what has gone into 6.10.2, I think the credit probably goes to the patch below.  It's nice to hear this improves performance too - that was an unexpected benefit.

If you're able to test with the HEAD, I'd be very interested to see your results there too.

Cheers,
        Simon

Fri Feb 20 14:32:00 GMT 2009  Ian Lynagh <igloo at earth.li>
  * MERGED: Rewrite of signal-handling (ghc patch; see also base and unix patches)
  Simon Marlow <marlowsd at gmail.com>**20090219103142
   Ignore-this: aca7c3e258224fadc6f0f2fee86b2971

   The API is the same (for now).  The new implementation has the
   capability to define signal handlers that have access to the siginfo
   of the signal (#592), but this functionality is not exposed in this
   patch.

   #2451 is the ticket for the new API.

   The main purpose of bringing this in now is to fix race conditions in
   the old signal handling code (#2858).  Later we can enable the new
   API in the HEAD.

   Implementation differences:

    - More of the signal-handling is moved into Haskell.  We store the
      table of signal handlers in an MVar, rather than having a table of
      StablePtrs in the RTS.

    - In the threaded RTS, the siginfo of the signal is passed down the
      pipe to the IO manager thread, which manages the business of
      starting up new signal handler threads.  In the non-threaded RTS,
      the siginfo of caught signals is stored in the RTS, and the
      scheduler starts new signal handler threads.