#4154: Deadlock in Chan module
---------------------------------+------------------------------------------
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: high | Milestone: 6.14.1
Component: libraries/base | Version: 6.12.3
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by simonmar):
* priority: normal => high
* os: Windows => Unknown/Multiple
* milestone: => 6.14.1
Comment:
I can't see a way to fix this in the implementation of `Chan` while
retaining the properties and the other operations it has. The problem is
that `readChan` holds empty the read end of the `Chan`, but `isEmptyChan`
and `unGetChan` (see #3527) also need to take the read end, so they
deadlock if there is a blocked reader on an empty `Chan`.
My suggestion is to deprecate both `isEmptyChan` and `unGetChan`, with a
message explaining the problem and directing people to `TChan` instead.
`TChan` works, but lacks the fairness property of `Chan`, and is probably
only suitable when you have a small number of readers. We could make an
`MVar` version with similar properties, but it wouldn't perform any better
than `TChan` and wouldn't be composable, so this seems the best
compromise:
* `Chan` has fairness, single-wakeup (good for multiple readers)
* `TChan` has `isEmptyChan` and `unGetChan`
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4154#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
