Re: [Haskell-cafe] interaction between OS processes
On Sat, Sep 01, 2007 at 09:12:30PM -0400, Albert Y. C. Lai wrote: Andrea Rossato wrote: loop s = do putStrLn s Most likely, the content of s sits in a local buffer and never leaves this process, following most OS conventions and as others point out. Another process waiting for it will deadlock. Most similar process deadlock problems are not specific to Haskell or even relevant to Haskell; they are misunderstandings of the underneath OS. I recommend every Haskell programmer to take an in-depth Unix course. Yes, I knew it was something related to the underneath OS. I'll have to study Unix seriously Thanks you guys for your kind attention. Andrea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] interaction between OS processes
Andrea Rossato wrote: Most likely, the content of s sits in a local buffer and never leaves this process, following most OS conventions and as others point out. Another process waiting for it will deadlock. Yes, I knew it was something related to the underneath OS. I'll have to study Unix seriously 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. Are you calling hFlush after writing to your pipe? b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] interaction between OS processes
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] interaction between OS processes
Albert Y. C. Lai wrote: 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. s/Clean/Cayenne/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] interaction between OS processes
Andrea Rossato wrote: loop s = do putStrLn s Most likely, the content of s sits in a local buffer and never leaves this process, following most OS conventions and as others point out. Another process waiting for it will deadlock. Most similar process deadlock problems are not specific to Haskell or even relevant to Haskell; they are misunderstandings of the underneath OS. I recommend every Haskell programmer to take an in-depth Unix course. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] interaction between OS processes
Hi, there's something I don't get about interaction among OS processes and Haskell handles/channels. Suppose I have a very small program that takes a line and prints it till you write quit: main = do s - getLine case s of quit - putStrLn quitting return () _ - loop s where loop s = do putStrLn s main This is a small interactive process I would like to talk to from another Haskell program, like the following one which, indeed, is just a wrapper around the first. Now, if I write a single line with quit, I get quitting back, otherwise the program doesn't work. I think I need some direction in order to understand how handles work. The same with channels, I'm afraid. Could you please point me in the right direction? Thanks for your kind attention. Andrea The not working code: import Control.Concurrent import System.Process import System.IO main = do c - runInteractiveCommand ./main2 loop c loop c@(i,o,e,p) = do s - getLine hPutStrLn i s hFlush i -- now i is closed, right? s' - hGetLine o putStrLn s' loop c ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
