Ticket #806 (new bug)

Opened 6 years ago

Last modified 17 months ago

hGetBufNonBlocking doesn't work on Windows

Reported by: titto@… Owned by:
Priority: normal Milestone: _|_
Component: libraries/base Version: 6.4.2
Keywords: Cc: Bulat.Ziganshin@…, Deewiant, ryani, Olathe
Operating System: Windows Architecture: x86
Type of failure: Runtime crash Difficulty: Moderate (less than a day)
Test Case: hGetBuf001 Blocked By:
Blocking: Related Tickets:

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

out Download (0.8 KB) - added by guest 6 years ago.
stdout
err Download (181.0 KB) - added by guest 6 years ago.
stderr

Change History

Changed 6 years ago by guest

  • attachment out Download added

stdout

Changed 6 years ago by guest

  • attachment err Download added

stderr

Changed 6 years ago by simonmar

  • summary changed from internal error: asyncRead# on threaded RTS with HAppS -threaded to hGetBufNonBlocking doesn't work with -threaded on Windows
  • component changed from Compiler to libraries/base
  • milestone set to 6.6

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).

Changed 5 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.

Changed 5 years ago by simonmar

  • milestone changed from 6.6 to 6.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.

Changed 5 years ago by simonmar

  • owner set to simonmar

Changed 5 years ago by simonmar

  • testcase set to hGetBuf001
  • difficulty changed from Unknown to Moderate (1 day)
  • summary changed from hGetBufNonBlocking doesn't work with -threaded on Windows to hGetBufNonBlocking doesn't work on Windows
  • milestone changed from 6.6.1 to 6.8

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.

Changed 5 years ago by guest

  • cc Bulat.Ziganshin@… added

Changed 4 years ago by simonmar

  • owner simonmar deleted

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

Changed 4 years ago by simonmar

  • milestone changed from 6.8 branch to _|_

Changed 4 years ago by Deewiant

  • cc Deewiant added

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

Changed 3 years ago by ryani

  • cc ryani added

Changed 2 years ago by simonmar

  • difficulty changed from Moderate (1 day) to Moderate (less than a day)

Changed 17 months ago by Olathe

  • cc Olathe added
  • failure set to 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.

Changed 17 months ago by Olathe

  • failure changed from None/Unknown to Runtime crash

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

Changed 17 months 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!

Changed 17 months 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).

Note: See TracTickets for help on using tickets.