ANNOUNCE: GHC 6.10.2 Release Candidate 1
simonmar at microsoft.com
Thu Mar 19 04:59:42 EDT 2009
> 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:
> 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:
> 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.
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
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
#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.
- 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.
More information about the Glasgow-haskell-users