[Haskell-cafe] I/O system brokenness with named pipes

[Donn Cave]

On Apr 11, 2008, at 6:15 AM, John Goerzen wrote:

> I wonder if we could document this behavior.  I rarely use non- 
> blocking I/O
> from C, and Haskell hides the fact that it's doing this, so the  
> behavior is
> non-intuitive.

I have run into this problem, with Network.Socket (socket).  If I  
remember right,
ktrace showed me what was happening.  This isn't my favorite thing  
about Haskell.
Is there even a means provided to set it back to blocking?  I  
couldn't find one,
had to write my own FFI.  It is not news to me that there is an issue  
with the
Haskell thread implementation here, but since any non-native library  
I/O will
similarly be blocking, we have to be able to live with this anyway.

> Actually, better yet, I wonder if we could *fix* this behavior.  Most
> programs can take a FIFO as arguments in a standard way, and it  
> seems to me
> that this violates the principle of least surprise.
>
> Unfortunately, since we're talking about open here, we can't use  
> select() or
> poll().  But I wonder if we couldn't use stat() to determine if  
> something is
> a named pipe, and if so, enter a loop where we try to open it  
> periodically?

I am having a little trouble following this.  Somewhere in the  
thread, the subject
of ReadWrite pipe behavior came up, apparently for whatever reason  
you get
non-blocking I/O this way too.  But as long as you don't do that,  
then all you need
for normal named pipe I/O is to set the file descriptor back to  
blocking ... right?
Is the loop to work around the Haskell non-blocking, or the ReadWrite  
non-blocking?

	Donn Cave, donn at avvanta.com