Opened 8 years ago

Last modified 22 months ago

#3937 new bug

Cannot killThread in listen/accept on Windows threaded runtime

Reported by: guest Owned by:
Priority: low Milestone:
Component: Runtime System Version: 6.12.1
Keywords: Cc:
Operating System: Windows Architecture: x86
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

The killThread is not able to kill threads accepting socket connections on Windows.

Run attached file either in GHCi:

runghc.exe ListenOn.hs

or compile threaded:

ghc --make -threaded ListenOn.hs

Resulting binary hangs.

Expected behavior: should finish without problems.

Non-threaded runtime produces expected behavior. Seems to work correctly on Linux.

Affected: ghc-6.10.4 and ghc-6.12.1.

Attachments (1)

ListenOn.hs (990 bytes) - added by guest 8 years ago.

Download all attachments as: .zip

Change History (13)

Changed 8 years ago by guest

Attachment: ListenOn.hs added

comment:1 Changed 8 years ago by simonmar

Milestone: 6.14.1

This is because on Windows we don't delegate blocking IO operations to an IO manager thread, as we do on Unix systems. Hopefully this will be fixed in 6.14.1 (maybe that's optimistic as nobody has volunteered to build a Windows version of the IO manager yet, but still).

One workaround is to explicitly fork a thread and pass the result back in an MVar. It's easy to abstract this into a little function.

comment:2 Changed 8 years ago by guest

Hmm... As far as I understand the code... we try hard to call fdReady just before calling accept. In theory fdReady should say false and accept should not be called at all until the socket will be back in ready to read state. So accept is not treated as blocking call, otherwise non-threaded runtime couldn't work at all... I'm pretty sure I'm missing something here.

MVar solution will not work as I really want it to stop listening on that socket.

Scenario is GHCi (interpreted) and :main, app-exit, :reload, :main. Exiting app by clean means (app-exit) does not work for me.

comment:3 Changed 8 years ago by simonmar

What code are you looking at? I don't see any calls to fdReady anywhere in network-2.2.1.5. Network.accept calls Network.Socket.accept, which calls the C accept directly when -threaded.

comment:4 Changed 7 years ago by igloo

Milestone: 7.0.17.0.2

comment:5 Changed 7 years ago by igloo

Milestone: 7.0.27.2.1

comment:6 Changed 6 years ago by igloo

Milestone: 7.2.17.4.1

comment:7 Changed 6 years ago by igloo

Milestone: 7.4.17.6.1
Priority: normallow

comment:8 Changed 5 years ago by igloo

Milestone: 7.6.17.6.2

comment:9 Changed 3 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:10 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:11 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:12 Changed 22 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.