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

[GHC]

#367: Infinite loops can hang Concurrent Haskell
------------------------------------------+---------------------------------
  Reporter:  simonpj                      |          Owner:                      
      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):

 While solving this problem in general may be quite hard, we might be able
 to allow users to annotate potentially time-consuming, non-allocating
 regions of code in a way that would allow them to be interrupted, by co-
 opting the mechanism we have for interruptible FFI calls. Namely,
 pthread_kill()'ing recalcitrant threads >:-) (alas, this won't work for
 Windows, but you can't have everything in life...)  E.g.

 {{{
 runInterruptibly (evaluate (last (repeat 1))
 }}}

 The primary difficulty of this scheme is making sure the computation is
 being done on threads which we can afford to terminate with extreme
 prejudice. This is easy for safe FFI calls, because we give up the
 capability before entering the foreign code. But a thread executing
 Haskell will generally have the capability, since it might GC.

 One answer might be: on entering such an annotated region, give up the
 capability, and make the thread do an InCall if it happens to hit
 something that needs GC'ing. Of course, this means we need to have a
 version of all the code being generated here to use different GC entry-
 points which do the InCall shindig (in the cases where this is useful,
 there shouldn't be very many of them, since the whole point is this is a
 non-allocating loop!) but this could cause a pretty massive expansion in
 overall code size. The benefit of such a scheme is that we only pay a cost
 entering such a region. We don't want to add any checks to the pre-
 existing GC functions, since we'll pay the cost for all programs, even
 ones not using this functionality.

 Another possibility is to still give up the capability, but to demand that
 any code covered by such an annotation be statically known never to make
 allocations. But it is probably too difficult to explain to the programmer
 under what circumstances allocation occurs, and I imagine many regions of
 code will allocate once or twice, but have large chunks inside which
 perform no allocation. On the other hand, it would be pretty nice if
 Haskell programmers could carve out a chunk of code, and say, "This is
 doing a very clever numeric calculation which should compile straight to
 something efficient which does no allocation."

 But I think the right answer here is to make it possible to run Haskell
 code *without* holding a capability, and then proceed from there.

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