[Haskell-cafe] Blocking IO & FIFOs
jason.dusek at gmail.com
Sun Oct 21 13:25:00 CEST 2012
2012/10/21 Donn Cave <donn at avvanta.com>:
> From Jason Dusek <jason.dusek at gmail.com>:
>> If I could somehow arrange to detect EOF when /tmp/exitpipe is
>> closed, then I might as well redirect 1 and 2 to FIFOs and wait
>> for them to EOF, collecting the output.
>> However, all of my experiments suggest that there is simply no
>> way in Haskell to detect the closing of the write end of a FIFO.
>> With `openFileBlocking', one can detect when a FIFO is *opened*;
>> but not when it is closed.
> [...] If I use POSIX I/O, it works fine. So it looks to me
> like there is indeed a way in Haskell to detect a closed FIFO,
> it just may not be Haskell I/O without a lot more work ironing
> out the possible causes of failure.
Sadly, I can not do Posix IO on handles or read a ByteString
from a Posix FD.
> 2) you need the named pipe only to detect command process
> exit, and you can still apply Haskell I/O to the more
> interesting data that accumulates in the command output
> disk file.
Writing data to disk for communicating with other processes
is not a good pattern, I think.
> And there may be an answer for my problems with Haskell I/O.
> Could be as simple as using openFileBlocking, which apparently
> isn't supported in the ghc I'm using. Could have something to
> do with the fine points of named pipes - for example, I
> believe you're supposed to open them O_RDWR in situations
> you'd think would call for O_READONLY. (Though the latter
> worked for me with POSIX I/O.)
It is okay to open it O_READONLY if blocking when there is no
writer is acceptable. For this application, it is.
> While I'm here ... I share the concern expressed in an earlier
> followup about the outputs from bash in runInteractiveProcess.
> This looks like a feature of runInteractiveProcess that makes
> it intrinsically something like a "code smell". input-only
> and output-only processes are commonly used and fairly
> tractable, where input-output processes are unusual and and
> fragile, so it's an unfortunate convenience. I think the idea
> is that you'd use createProcess specifying only the input
I am averse to adding "just in case" code that may not do
anything; too much system level code attains an air of mystery
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
More information about the Haskell-Cafe