[Haskell-cafe] interaction between OS processes
Albert Y. C. Lai
trebla at vex.net
Sun Sep 2 13:56:44 EDT 2007
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
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.
More information about the Haskell-Cafe