Opened 13 years ago

Last modified 7 weeks ago

#806 new bug

hGetBufNonBlocking doesn't work on Windows

Reported by: titto@… Owned by: Phyx-
Priority: normal Milestone: 8.10.1
Component: Core Libraries Version: 6.4.2
Keywords: Cc: Bulat.Ziganshin@…, Deewiant, ryani, Olathe, dagitj@…, core-libraries-committee@…
Operating System: Windows Architecture: x86
Type of failure: Runtime crash Test Case: hGetBuf001
Blocked By: #11394 Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


All HAppS ( applications fail with an internal error: asyncRead# when compiled with the -threaded option.

To reproduce the error:

  • compile any of the apps in the example subdirectory with -threaded and access it over the net (http://localhost:8000).

For example:

ghc --make -v -fallow-overlapping-instances -fglasgow-exts -threaded httpd.hs -o httpd

The same programs compiled without -threaded work fine.

Tested on Windows XP with latest SP/patches and gcc 6.4.2. Let me know if you would like more info or the full compilation trace.

Attachments (2)

out (870 bytes) - added by guest 13 years ago.
err (181.0 KB) - added by guest 13 years ago.

Download all attachments as: .zip

Change History (24)

Changed 13 years ago by guest

Attachment: out added


Changed 13 years ago by guest

Attachment: err added


comment:1 Changed 13 years ago by simonmar

Component: Compilerlibraries/base
Milestone: 6.6
Summary: internal error: asyncRead# on threaded RTS with HAppS -threadedhGetBufNonBlocking doesn't work with -threaded on Windows

The bug is in hGetBufNonBlocking, which bogusly uses asyncRead on Windows. I've changed the title of the ticket to reflect this. As a workaround for now, you could use hGetBuf (I believe the NonBlocking variants aren't actually non-blocking on Windows anyway, this is another bug).

comment:2 Changed 12 years ago by igloo

Rene de Visser reports that this bug means that fps 0.8 (and software that uses fps) triggers this bug in ghci, meaning anything using this cannot be used interactively.

comment:3 Changed 12 years ago by simonmar


I've made it not crash now. It still doesn't have the right non-blocking behaviour, but that'll have to wait.

comment:4 Changed 12 years ago by simonmar

Owner: set to simonmar

comment:5 Changed 12 years ago by simonmar

difficulty: UnknownModerate (1 day)
Summary: hGetBufNonBlocking doesn't work with -threaded on WindowshGetBufNonBlocking doesn't work on Windows
Test Case: hGetBuf001

Changing the title of this bug: hGetBufNonBlocking doesn't work at all on Windows, -threaded or not. The problem is that the I/O system doesn't have any non-blocking primitives, unlike on Unix where we use O_NONBLOCK.

One way to fix this would be to start using overlapped I/O on Widnows, together with the IO manager thread to wait for blocking I/O operations. This would be a good thing, but it probably isn't going to happen for 6.6.1.

comment:6 Changed 12 years ago by guest

Cc: Bulat.Ziganshin@… added

comment:7 Changed 11 years ago by simonmar

Owner: simonmar deleted

I'm not going to fix this anytime soon, so remove my lock

comment:8 Changed 11 years ago by simonmar

Milestone: 6.8 branch_|_

comment:9 Changed 11 years ago by Deewiant

Cc: Deewiant added

Perhaps noting this explicitly in the documentation of hGetBufNonBlocking is in order?

comment:10 Changed 10 years ago by ryani

Cc: ryani added

comment:11 Changed 9 years ago by simonmar

difficulty: Moderate (1 day)Moderate (less than a day)

comment:12 Changed 8 years ago by Olathe

Cc: Olathe added
Type of failure: None/Unknown

On Windows, this breaks any code that wants to read from stdin using any libraries that use lazy ByteStrings internally (and, obviously, anyone who just uses its getContents directly).

This stymied me when I was trying to speed up some library code for a programming contest, since some participants (like me) would be testing their entries on their Windows machines.

comment:13 Changed 8 years ago by Olathe

Type of failure: None/UnknownRuntime crash

Sorry, it looks like I somehow changed the type of failure.

comment:14 Changed 8 years ago by simonmar

I appreciate the problem. However, in order to fix this we have write a new Windows backend for the IO library that uses the Win32 API directly, rather than the current one that uses the Windows emulation of the POSIX API. The current version doesn't support non-blocking I/O. I'd really like a Win32 expert to step up and volunteer to do this!

comment:15 Changed 8 years ago by simonmar

Incidentally, I think for the case of lazy bytestrings in particular, this should be fixed in GHC 7.0.1 because we will no longer be using hGetBufNonBlocking in the implementation of lazy bytestrings' hGetContents. (I'm currently waiting for the bytestring patch to be reviewed by the bytestring maintainers; see also #3808).

comment:16 Changed 6 years ago by morabbin

Patch for #3808 accepted; ought this be marked fixed?

comment:17 in reply to:  16 Changed 6 years ago by simonmar

Replying to morabbin:

Patch for #3808 accepted; ought this be marked fixed?

No, but depending on what happens in #4144 this might get fixed as a result of that.

comment:18 Changed 6 years ago by dagit

Cc: dagitj@… added

comment:19 Changed 4 years ago by thoughtpolice

Component: libraries/baseCore Libraries
Owner: set to ekmett

Moving over to new owning component 'Core Libraries'.

comment:20 Changed 4 years ago by ekmett

Cc: core-libraries-committee@… added
Owner: ekmett deleted

Relinquishing ownership of this ticket as this seems to be more of a runtime system issue.

comment:21 Changed 6 months ago by Phyx-

Blocked By: 11394 added
Milestone: 8.8.1
Owner: set to Phyx-

comment:22 Changed 7 weeks ago by osa1


Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.