
Bryan O'Sullivan wrote:
Your problem may be buffering-related (I haven't read your code to check), but if so, there's a fair likelihood that it has nothing to do with the OS. GHC's runtime does its own buffer management on Handles. It's quite possible that your deadlock lies at that level, rather than anything lower.
Although GHC's runtime kind of re-invents buffering, it still follows the Unix convention, i.e., if stdio is determined to be attached to a tty, then default to line buffering, else default to block buffering. Indeed, I wager that it bothers to re-invent buffering because of some other technical necessity (green-threading comes to mind), and if it goes out of its way to re-invent buffering, why, of all conceivable conventions, the Unix convention again? E.g., why not take this opportunity to spare beginners a nasty surprise and default to line buffering across the board? It seems to me clearly that the answer is precisely to spare the Unix-informed programmers a nasty surprise. Therefore although GHC's runtime does its own buffering, a Unix education still informs you of what it does. The problem is the same and the solution is the same. Even taking a step back, even if GHC or some other Haskell runtimes or some other language runtimes or even other VMs and OSes do not follow the Unix convention, a Unix course still serves to alert you of buffering issues, that buffering can be weird, that the OS does its weird buffering, that a language runtime may or may not add yet its weird buffering... You will develop a habit of double-checking with the docs and testing, not a habit of just assuming that what you see on a tty is what you get on a pipeline. Along the way, you will also see why getChar waits for a newline (and why sometimes even a newline doesn't suffice)... It is similar to saying, if you use a high-level language on x86, you don't have to learn low-level 680x0. Ah, but knowing low-level 680x0 informs you of certain issues of the high-level language (e.g., performance) and how to use it more successfully. This is despite 680x0 is not the x86 you use. It is similar to saying, if you use Haskell, you don't have to learn dependent typing. Ah, but knowing dependent typing informs you of certain typing issues and how to use the Haskell type system more successfully. This is despite tutorials on dependent typing talk about Clean or Coq rather than the Haskell you use. It is similar to saying, if you use Java and C#, you don't have to learn Haskell. Ah, but knowing Haskell informs you of certain programming issues and how to use Java and C# more successfully. This is despite Haskell does not talk about objects. It is education and personal growth. It is not just vocational training.