[GHC] #6057: hGetBufNonBlocking blocks the underlying handle on Windows
GHC
cvs-ghc at haskell.org
Wed May 2 07:59:38 CEST 2012
#6057: hGetBufNonBlocking blocks the underlying handle on Windows
---------------------------------+------------------------------------------
Reporter: cetinsert | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version: 7.0.4
Keywords: | Os: Windows
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by cetinsert):
Although I do not have code, I have pinned the problem down to following
steps:
1. Create sockets
2. Convert sockets to handles
3. Set handles to no buffering
4. Do handshake IO using operations on handles
5.
[https://github.com/corsis/splice/commit/5e73712b0c01e1ccad158635433fd04d28149306#commitcomment-1280935
Set same handles to no buffering again on a different Haskell thread]
6. Observe the order-dependent behavior mentioned in this report:
{{{
a >- b $ j -- forks and does step 5 on a Haskell thread
b >- a $ j -- forks and does step 5 on a Haskell thread
}}}
differs from
{{{
b >- a $ j -- forks and does step 5 on a Haskell thread
a >- b $ j -- forks and does step 5 on a Haskell thread
}}}
Eliminating step 5 makes the problem go away:
{{{
a >- b $ j
b >- a $ j
}}}
equals
{{{
b >- a $ j
a >- b $ j
}}}
in behaviour.
How can this be explained? It seems to happen both on Windows and Linux.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6057#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list