[GHC] #367: Infinite loops can hang Concurrent Haskell

[GHC]

#367: Infinite loops can hang Concurrent Haskell
------------------------------------------+---------------------------------
  Reporter:  simonpj                      |          Owner:  ezyang              
      Type:  bug                          |         Status:  new                 
  Priority:  lowest                       |      Milestone:  _|_                 
 Component:  Compiler                     |        Version:  6.4.1               
Resolution:  None                         |       Keywords:  scheduler allocation
        Os:  Unknown/Multiple             |   Architecture:  Unknown/Multiple    
   Failure:  Incorrect result at runtime  |     Difficulty:  Unknown             
  Testcase:                               |      Blockedby:                      
  Blocking:                               |        Related:                      
------------------------------------------+---------------------------------

Comment(by ezyang):

 OK, once I get my validate running (failing, due to a certain someone,
 wink), I will push the patch, plus this docu patch:

 {{{
 <varlistentry>
   <term>
     <option>-falways-yield</option>
     <indexterm><primary><option>-falways-
 yield</option></primary></indexterm>
   </term>
   <listitem>
       <para>Tells GHC to always emit a pre-emption check on entry
     points to functions. This means that threads that run in tight
     non-allocating loops will get preempted in a timely fashion;
     otherwise, GHC may never manage to interrupt such a loop.  This
     imposes a very slight performance impact but inflates binary sizes
     by about 5%, so it is not enabled by default.  Note that if you
     would like to guarantee that threads can always be interrupted,
     you will need to compile all libraries with this flag.</para>
   </listitem>
 </varlistentry>
 }}}

 What are we going to do with information about CPU hogging primitives?
 There are lots of unsafe primitives which can cause GHC to segfault or
 jump to arbitrary code, so mostly this information would have to be
 advisory for Safe Haskell implementors, who would know if one of these
 primitives were called it better be doing bounds checks, etc. We can't
 forcibly terminate the primops, since they're fat machine instructions and
 don't give up the capability?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/367#comment:31>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler