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@avvanta.com