Bug with readFile and named pipes
Simon Marlow
simonmar at microsoft.com
Thu Aug 23 05:37:50 EDT 2001
> In local.glasgow-haskell-bugs, you wrote:
> > Programs that read from a named pipe usually block until a
> writer opens
> > the pipe and writes something to it. The following program,
> >
> > main = putStr =<< readFile "/tmp/p"
> >
> > (where "/tmp/p" refers to a named pipe) exhibits this behavour when
> > compiled with HBC or when run with runhugs, but *not* when
> compiled with
> > GHC. Instead the program immediately exists, returning the
> empty string.
>
> I don't know if we`re talking about different things, but when I
> played around with fifos (e.g. For TCP/Hugs :-), I noticed that it is
> recommended to open the FIFO for *writing* *before* *opening* it for
> *reading*, even if you`re not going to write to it yourself.
>
> I wouldn`t want readFile opening my file for writing under
> normal cases,
> so I'd recommend you use a hack which opens the file for
> writing first.
>
> One could imagine that readFile tests the filetype and does
> The Right Thing(TM), but I`m not sure I want that, either.
There was a long thread about this a while back (subject "Blocking I/O
and FIFOs"). The conclusion was that the behaviour varies between OSs:
the behaviour Thomas described occurs on FreeBSD, but not Linux or
Solaris. POSIX appears to be ambiguous on the subject.
Opening the FIFO for writing is a reasonable workaround. Note that we
have to do the nonblocking open for multi-threading, otherwise you could
block the whole process. Another alternative is to use the Posix
library, where you get full control over what kind of open() is
performed, but you won't be able to use this in conjunction with
concurrency.
Cheers,
Simon
More information about the Glasgow-haskell-bugs
mailing list