#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
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
