Thread status constants

Jost Berthold berthold at
Sat Jul 19 18:43:02 UTC 2014

> Message: 2
> Date: Sat, 19 Jul 2014 15:00:17 +1000
> From: Kyle Van Berendonck <kvanberendonck at>
> To: "ghc-devs at" <ghc-devs at>
> Subject: Thread status constants
> Message-ID:
> 	<CAFSvR6A3maSWngY=GJdATvGPjTAyuPokXZ5=rLtLT=EbYdSLKA at>
> Content-Type: text/plain; charset="utf-8"
> Hi,
> I found these:
> They go only 0-14, so there's some long chains of branches and stuff in hot
> paths that could be cleaned up into single &-masked branches by changing
> these into a set of flags.
> And then I saw these:
> Where does 16 and 17 come from -- I couldn't find them in the header files
> anywhere?
> Kyle

Hi Kyle,

I had a look at these constants just recently.

About 16 and 17, see here:

About the others:The block reasons received two updates just recently.
Turns out that the eventlog (GHC's post-mortem tracing for threadscope 
et al.) expects these states to have particular values (those in 
includes/rts/Constants.h, consider them a fixed ABI for the time being).
See here for the story:

NB: Darn... base still uses GHC-7.8.2 constants. Thanks for the pointer!

About your proposal to use bit masks:

Did you find some of those hot paths?
I believe (believe, unchecked...) that there are not too many places 
where a complete switch over all possible reasons is done (apart from 
debug output maybe); the typical use is rather to compare to one single 
constant than to all. So the performance might not increase too much 
from optimisations. Again, just a hunch, not verified.

If the RTS contains code specialised to the current constants, these 
places need to be kept symbolic, to avoid future breakage when new 
states are added.

A fix which removes the tight implicit dependency of ghc-events from the 
constants in includes/rts/Constants.h is pending, btw.

/ Jost

More information about the ghc-devs mailing list