In programs with a substantial number of threads, the error messages like "indefinitely blocked" are not very helpful, because there is no indication as to which thread blocked. Having the source location of the 'fork' or so, would be much more helpful.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
It sounds like it would be pretty easy to add the thread identifier (indeed, you can already get that info if you compile with -debug and enable RTS tracing with +RTS -D, look for the "resurrecting thread" message). Source code identifier sounds a little bit tougher though; does GHC even let us do that without making forkIO inlined?
It seems like the recently merged implicit-parameter-based stack-trace work (see D578) could be quite useful for this. Blocking actions could take an implicit SrcLoc which could be provided along with the error in the event of indefinite blocking.
It seems like we have the pieces in place to address this in 7.12. Milestoning appropriately
There are a few questions that remain, however,
What sort of stack trace should the exception carry? At the moment we have a number of source location representations scattered about base (which will hopefully soon be cleaned up; see #10068)