Opened 11 years ago

Last modified 2 years ago

#806 new bug

hGetBufNonBlocking doesn't work on Windows

Reported by: titto@… Owned by:
Priority: normal Milestone:
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: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

All HAppS (http://happs.org/HAppS/README.html) 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 11 years ago.
stdout
err (181.0 KB) - added by guest 11 years ago.
stderr

Download all attachments as: .zip

Change History (22)

Changed 11 years ago by guest

Attachment: out added

stdout

Changed 11 years ago by guest

Attachment: err added

stderr

comment:1 Changed 11 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 11 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 11 years ago by simonmar

Milestone: 6.66.6.1

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 11 years ago by simonmar

Owner: set to simonmar

comment:5 Changed 11 years ago by simonmar

difficulty: UnknownModerate (1 day)
Milestone: 6.6.16.8
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 10 years ago by guest

Cc: Bulat.Ziganshin@… added

comment:7 Changed 10 years ago by simonmar

Owner: simonmar deleted

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

comment:8 Changed 10 years ago by simonmar

Milestone: 6.8 branch_|_

comment:9 Changed 9 years ago by Deewiant

Cc: Deewiant added

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

comment:10 Changed 9 years ago by ryani

Cc: ryani added

comment:11 Changed 8 years ago by simonmar

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

comment:12 Changed 7 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 7 years ago by Olathe

Type of failure: None/UnknownRuntime crash

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

comment:14 Changed 7 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 7 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 4 years ago by morabbin

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

comment:17 in reply to:  16 Changed 4 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 4 years ago by dagit

Cc: dagitj@… added

comment:19 Changed 3 years ago by thoughtpolice

Component: libraries/baseCore Libraries
Owner: set to ekmett

Moving over to new owning component 'Core Libraries'.

comment:20 Changed 2 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.

Note: See TracTickets for help on using tickets.