Ticket #806 (new bug)

Opened 2 years ago

Last modified 3 days ago

hGetBufNonBlocking doesn't work on Windows

Reported by: titto@kamus.it Assigned to:
Priority: normal Milestone: _|_
Component: libraries/base Version: 6.4.2
Severity: normal Keywords:
Cc: Bulat.Ziganshin@gmail.com, Deewiant, ryani Difficulty: Moderate (1 day)
Test Case: hGetBuf001 Operating System: Windows
Architecture: x86

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 (0.8 kB) - added by guest on 06/26/06 22:57:40.
stdout
err (181.0 kB) - added by guest on 06/26/06 23:00:07.
stderr

Change History

06/26/06 22:57:40 changed by guest

  • attachment out added.

stdout

06/26/06 23:00:07 changed by guest

  • attachment err added.

stderr

07/10/06 05:22:26 changed 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).

09/25/06 05:55:51 changed 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.

09/27/06 08:06:19 changed 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.

11/17/06 07:11:40 changed by simonmar

  • testcase changed.
  • owner set to simonmar.

12/07/06 08:03:00 changed 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.

07/03/07 03:23:38 changed by guest

  • cc set to Bulat.Ziganshin@gmail.com.

09/03/07 07:35:23 changed by simonmar

  • owner deleted.

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

11/12/07 06:27:22 changed by simonmar

  • milestone changed from 6.8 branch to _|_.

06/19/08 11:02:05 changed by Deewiant

  • cc changed from Bulat.Ziganshin@gmail.com to Bulat.Ziganshin@gmail.com, Deewiant.

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

12/02/08 14:39:53 changed by ryani

  • cc changed from Bulat.Ziganshin@gmail.com, Deewiant to Bulat.Ziganshin@gmail.com, Deewiant, ryani.