Windows supports

[kazu-yamamoto]

All test cases are passed on Windows now.

• Workaround to kill the base thread which waits for dispatchers blocked by recvMsg (windowsThreadBlockHack from Warp)
  • IO blocked thread cannot be killed by killThread. So, spawning a new thread for IO so that he parent thread can be killed.
• No server reader from a connected socket: recvMsg catches all packets (see below)
• Cheap timer
• Test cases of long session
• Closure in the server side

[kazu-yamamoto]

UDP socket category:

• a) Wildcard socket for accepting (*:443, *:*)
• b) Interface specific socket for accepting (127.0.0.1:443, *:*)
• c) Connected socket (127.0.0.1:443, pa:pp)

Windows UDP socket implementation for receiving (no best match, sigh):

1. Looking into only destination addr/port only. So, b) and c) have the same priority.
2. b)/c) wins against a).
3. Among b) and c), the first-created one wins.

Requirement: we want to use c) for sending on a QUIC server.

If a) is used for accepting, dispatching packets among c) by kernel fails due to 3). So, b) should be used for accepting/receiving. b) wins against c)s thanks to 3).

Our architecture:

• c) for sending
• b) for receiving all packets
  • a) such as 0.0.0.0 cannot be specified in scAddresses. Use b) such as 127.0.0.1.

[kazu-yamamoto]

@Mistuke I would like to have the timer manager on Windows. I wonder why it is not exported. If GHC.Event is exported:

• getSystemTimerManager works thanks to poll() syscall
• getSystemEventManager returns Nothing

And you can replace the backend of the timer manager and implement the IO manager in the future if you wish.

So, I think that GHC should just export GHC.Event even on Windows. What do you think?

[Mistuke]

So, I think that GHC should just export GHC.Event even on Windows. What do you think?

@kazu-yamamoto the problem is that as you say the TimerManager requires the poll interface which Windows doesn't implement. Windows isn't POSIX so doesn't implement every interface. In this case there's only select available.

Newer Windows have added WSAPoll() to help port software but until Windows 10 it contains a nasty bug, but also would only work on Sockets not any descriptor.

• So, I think that GHC should just export GHC.Event even on Windows. What do you think?

It's a bit of a tangled web to un-weave.. There's no actual implementation that would work for MIO. For the new I/O manager there's a timer manager being exposed through GHC.Event.Windows with a similar interface. See https://github.com/ghc/ghc/blob/f115c382a0b0cc9299e73bcb8a11ad97c5fe7c57/libraries/base/GHC/Event/Windows.hsc#L43

Note that Hoogle and Hackage won't show you this because they build the libraries for one OS in order to index it, so they build for Linux, leaving out any MacOS or Windows specific bits.

It can't really be exposed through GHC.Event because at the moment I still have to deal with MIO being there. For MIO there's no implementation for getSystemTimerManager nor getSystemEventManager. So there would be nothing to export.

[kazu-yamamoto]

@Mistuke Thanks. I misunderstood that GHC.Event.Windows is not exported yet. I will make use of it!

[kazu-yamamoto]

@Mistuke Many test cases now pass on Windows! I respect your work! Bravo!

[Mistuke]

@Mistuke Many test cases now pass on Windows! I respect your work! Bravo!

Yay! good to hear!

[kazu-yamamoto]

@BernardoGomesNegri quic library now works well on Windows. Probably the performance of servers is not good but it's better than nothing.

[BernardoGomesNegri]

Very nice code! A few questions (purely out of curiosity): is the base thread ever killed? If so, when?
What is the difference between recvMsg/sendMsg and normal recv/send? I don't know a lot about networking.

[kazu-yamamoto]

You can use stop to kill the base thread of a server.

recvMsg can get my address/port in addition to peer address/port.