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, [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
