Winsock Fixes by Joannis · Pull Request #3433 · apple/swift-nio

Joannis · 2025-11-03T13:57:52Z

This PR gets TCP (Servers) on Windows mostly working. I'll annotate my PR for clarity.

The one bug:
If you open a TCP client connection to a Windows TCP server, it doesn't read/write yet until a second connection comes in. This happens because reregister0 is called after WSAPoll is called - but WSAPoll isn't woken up to know this so it doesn't know the new socket requests read/writes/...

Also the EventLoop cannot be woken up during el.execute { .. } because SleepEx isn't running. WSAPoll doesn't respond to this signal it seems.

This makes the TCP server functionality not yet usable, but I thought with this draft we could figure out what I'm missing.

Alternative considered: We can make WSAPoll limited to wake up every 1 ms for example, that way we can still get to these events at some point.

This results in a partially working winsock

BUG: A connection currently only becomes communicative after a new connection comes in. But Windows TCP is working after that.

Joannis · 2025-11-03T14:00:04Z

Sources/NIOPosix/ThreadWindows.swift

+            var realHandle: HANDLE? = nil
+            let success = DuplicateHandle(
+                GetCurrentProcess(),    // Source process
+                GetCurrentThread(),     // Source handle (pseudo-handle)
+                GetCurrentProcess(),    // Target process
+                &realHandle,           // Target handle (real handle)
+                0,                     // Desired access (0 = same as source)
+                false,                 // Inherit handle
+                DWORD(DUPLICATE_SAME_ACCESS) // Options
+            )


Windows gives pseudo handles by default, so they're always correct for the current thread. However, when spawning work on another thread, this handle results in getting the incorrect ThreadID, causing QueueUserAPC to notify the wrong (or non-existing) thread. This in turn prevents SleepEx from waking up the eventloop

We don't use QueueUserAPC anymore. However the general statement remains true. Maybe we can rework the comments, to be less about QueueUserAPC. We maybe also want to document somewhere why QueueUserAPC is not an option.

Joannis · 2025-11-03T14:00:11Z

Sources/NIOPosix/ThreadWindows.swift


    static var currentThread: ThreadOpsSystem.ThreadHandle {
-        GetCurrentThread()
+        var realHandle: HANDLE? = nil


Likewise here

Joannis · 2025-11-03T14:01:49Z

Sources/NIOPosix/SelectorWSAPoll.swift

        registrationID: SelectorRegistrationID
    ) throws {
-        fatalError("TODO: Unimplemented")
+        if let index = self.pollFDs.firstIndex(where: { $0.fd == UInt64(fileDescriptor) }) {


Deregistering is just removing the FD. However, we can't just remove it here as we're iterating over the same pollFDs at the same time. deregister0 is called down the stack of try body((SelectorEvent(io: selectorEvent, registration: registration))). So the available indices of pollFDs changes causing a crash

can we add this comment to the local array that we use for this? so that we document what this array is used for?

Joannis · 2025-11-03T14:02:17Z

Sources/NIOPosix/SelectorWSAPoll.swift

@@ -131,6 +133,19 @@ extension Selector: _SelectorBackendProtocol {

                    try body((SelectorEvent(io: selectorEvent, registration: registration)))


This line often calls deregister0 indirectly, so we effectively can't mutate pollFDs in deregister0

Joannis · 2025-11-03T14:02:33Z

Sources/NIOPosix/SelectorWSAPoll.swift

+                // now clean up any deregistered fds
+                // In reverse order so we don't have to copy elements out of the array
+                // If we do in in normal order, we'll have to shift all elements after the removed one
+                for i in self.deregisteredFDs.indices.reversed() {
+                    if self.deregisteredFDs[i] {
+                        // remove this one
+                        let fd = self.pollFDs[i].fd
+                        self.pollFDs.remove(at: i)
+                        self.deregisteredFDs.remove(at: i)
+                        self.registrations.removeValue(forKey: Int(fd))
+                    }
+                }


Do the deregister0 work of cleaning up after the polling is done

Joannis · 2025-11-03T14:03:00Z

Sources/NIOPosix/SelectorWSAPoll.swift

    func initialiseState0() throws {
        self.pollFDs.reserveCapacity(16)
+        self.deregisteredFDs.reserveCapacity(16)
+        self.lifecycleState = .open


Lifecycle never became open yet

Joannis · 2025-11-03T14:03:22Z

Sources/NIOPosix/SocketChannel.swift

+        #if os(Windows)
+        case .winsock(WSAEWOULDBLOCK):
+            return false
+        #endif


accept returns WSAEWOULDBLOCK

Why doesn't the current logic for syscall(blocking: true) cover this?

Joannis · 2025-11-03T14:03:45Z

CC @fabianfett and @zamderax

This way new TCP connections will be functional

Lukasa · 2025-11-03T22:22:33Z

Sources/NIOPosix/BaseSocketChannel.swift

+        #if os(Windows)
+        if
+            let err = err as? IOError,
+            case .winsock(WSAEWOULDBLOCK) = err.error


How is this case reached?

What I've found is that when WSAPoll gives the server socket a .read event when a client is inbound:

Server accepts the client through readable() -> readable0() -> ServerSocketChannel.readFromSocket()

The socket.accept(..) finds a socket

SelectableEventLoop repeats this again again to get another read (see maxMessagesPerRead)

This time, socket.accept(..) runs into WinSDK.INVALID_SOCKET

Gets the error using WSAGetLastError()

The error ends up reaching .winsock(WSAEWOULDBLOCK)

In hindsight, I just noticed that accept() returns an optional so I'll leverage that instead.

Sources/NIOPosix/SelectorWSAPoll.swift

Lukasa · 2025-11-03T22:38:11Z

Sources/NIOPosix/SocketChannel.swift

+        #if os(Windows)
+        case .winsock(WSAEWOULDBLOCK):
+            return false
+        #endif


Why doesn't the current logic for syscall(blocking: true) cover this?

Sources/NIOPosix/SocketChannel.swift

It seems there's no socketpair API on Windows

It's used pretty heavily, and writev is implemented on Windows.

3a4oT · 2025-12-15T10:59:55Z

Hey guys, is it something that can be accepted? What is the status of this PR? Can someone please share plans for the Windows support roadmap?

Joannis · 2026-01-19T09:44:12Z

@3a4oT this needs a proper review first. And there's one gaping hole in the implementation's polling still that needs fixing.
It uses a loopback socket so we can wake up the EventLoop, but that exposes a literal server socket as a temporary measure. I didn't find a way to use a pipe with WSAPoll yet, but IMO this is unacceptable to merge before we find a solution to that. You can rely on my branch for demo-level code to try out NIO on Windows.

Hopefully I'll figure that out soon.

Joannis · 2026-01-19T09:45:07Z

Sources/NIOPosix/SelectorWSAPoll.swift

+    private static func createWakeupSocketPair() throws -> (NIOBSDSocket.Handle, NIOBSDSocket.Handle) {
+        // Create a UDP socket to receive wakeup signals
+        let readSocket = try NIOBSDSocket.socket(domain: .inet, type: .datagram, protocolSubtype: .default)
+
+        do {
+            // Bind to loopback on an ephemeral port
+            var addr = sockaddr_in()
+            addr.sin_family = ADDRESS_FAMILY(AF_INET)
+            addr.sin_addr.S_un.S_addr = WinSDK.htonl(UInt32(bitPattern: INADDR_LOOPBACK))
+            addr.sin_port = 0  // Let the system assign a port
+
+            try withUnsafeBytes(of: &addr) { addrPtr in
+                let socketPointer = addrPtr.baseAddress!.assumingMemoryBound(to: sockaddr.self)
+                try NIOBSDSocket.bind(socket: readSocket, address: socketPointer, address_len: socklen_t(MemoryLayout<sockaddr_in>.size))
+            }
+
+            // Get the assigned port
+            var boundAddr = sockaddr()
+            var size = Int32(MemoryLayout<sockaddr>.size)
+            try NIOBSDSocket.getsockname(socket: readSocket, address: &boundAddr, address_len: &size)
+
+            // Create the write socket
+            let writeSocket = try NIOBSDSocket.socket(domain: .inet, type: .datagram, protocolSubtype: .default)
+
+            do {
+                // Connect the write socket to the read socket's address
+                guard try NIOBSDSocket.connect(socket: writeSocket, address: &boundAddr, address_len: size) else {
+                    throw IOError(winsock: WSAGetLastError(), reason: "connect")
+                }
+                return (readSocket, writeSocket)
+            } catch {
+                _ = try? NIOBSDSocket.close(socket: writeSocket)
+                throw error
+            }
+        } catch {
+            _ = try? NIOBSDSocket.close(socket: readSocket)
+            throw error
+        }
    }


This is the code that needs to be fixed.

Joannis · 2026-01-19T09:45:59Z

Sources/NIOPosix/System.swift


 import CNIOWindows

+let IPPROTO_UDP = Int32(17)


IPPROTO_UDP is of IPPROTO type on Windows. Windows has some weird mappings of POSIX constants

Joannis · 2026-01-19T09:47:32Z

Sources/NIOPosix/System.swift

    static var UIO_MAXIOV: Int {
-        fatalError("unsupported OS")
+        // TODO: This is a placeholder value. Find the correct one for Windows.
+        return 64


This variable doesn't formally exist on Windows, but vector writing does work on Windows. We should really make it unavailable for Windows, and update all dependencies that indirectly use this constant. I had a few places that were affected

fabianfett · 2026-02-03T08:55:48Z

Sources/NIOPosix/SelectorGeneric.swift

+    @usableFromInline
+    var deregisteredFDs = [Bool]()


Would it make sense to just store indexes here? This would prevent us from linear searching the pollFDs. Please also add a comment what we use this array for.

fabianfett · 2026-02-03T08:58:39Z

Sources/NIOPosix/SelectorWSAPoll.swift

+
+            try withUnsafeBytes(of: &addr) { addrPtr in
+                let socketPointer = addrPtr.baseAddress!.assumingMemoryBound(to: sockaddr.self)
+                try NIOBSDSocket.bind(socket: readSocket, address: socketPointer, address_len: socklen_t(MemoryLayout<sockaddr_in>.size))


Using sockaddr_in is weird, as we have previously cast the pointer to sockaddr.

fabianfett · 2026-02-10T15:59:11Z

we will also need to make the CI green

Lukasa · 2026-03-10T15:07:52Z

Is this pending a review? What's the current status of this work?

Joannis · 2026-03-10T15:59:11Z

Yes, it is pending review

Joannis added 2 commits November 3, 2025 14:03

Fix the ability to spawn work on the Windows EventLoop

43c5d7d

This results in a partially working winsock

Allow a TCP server on Windows to accept connection

f59cfef

BUG: A connection currently only becomes communicative after a new connection comes in. But Windows TCP is working after that.

Joannis commented Nov 3, 2025

View reviewed changes

Joannis marked this pull request as ready for review November 3, 2025 14:22

Temporary fix: wake up WSAPoll after 1ms - always

10bb556

This way new TCP connections will be functional

Joannis mentioned this pull request Nov 3, 2025

Windows support hummingbird-project/hummingbird#747

Open

Lukasa reviewed Nov 3, 2025

View reviewed changes

Joannis added 6 commits November 4, 2025 11:05

Revert Windows WSAEWOULDBLOCK logic

05caf55

If accept() runs into WSAEWOULDBLOCk - return nil

d2a1ed1

Revert function signature change

17f30b6

Use an event FD based on a datagram socket

00a3a0b

It seems there's no socketpair API on Windows

Stub the value for UIO_MAXIOV on Windows

691073c

It's used pretty heavily, and writev is implemented on Windows.

When connect gets an error WSAEWOULDBLOCK, return false

3b99cc4

Joannis requested review from Lukasa and fabianfett December 18, 2025 18:04

Joannis commented Jan 19, 2026

View reviewed changes

fabianfett reviewed Feb 4, 2026

View reviewed changes

Joannis added 2 commits February 4, 2026 20:17

Modify loopback socket to be a UNIX Domain Socket

445d1d3

Cleanup deregisteredFDs

9332b56

Joannis force-pushed the jo/winsock-fixes branch from 8c67972 to 9332b56 Compare February 4, 2026 19:54

Joannis requested a review from fabianfett February 6, 2026 14:42

Merge branch 'main' into jo/winsock-fixes

2b99e33

Compile out Windows-only default: clause on other platforms

997a749

Joannis added 4 commits February 15, 2026 20:11

IPPROTO_UDP.rawValue on Windows

dea37d9

Formatting

c42a549

Merge branch 'main' into jo/winsock-fixes

aedcbf4

Merge branch 'main' into jo/winsock-fixes

3905773

		@@ -131,6 +133,19 @@ extension Selector: _SelectorBackendProtocol {

		try body((SelectorEvent(io: selectorEvent, registration: registration)))

Conversation

Joannis commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Joannis Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fabianfett Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Joannis commented Nov 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

3a4oT commented Dec 15, 2025

Uh oh!

Joannis commented Jan 19, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fabianfett commented Feb 10, 2026

Uh oh!

Lukasa commented Mar 10, 2026

Uh oh!

Joannis commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Joannis commented Nov 3, 2025 •

edited

Loading

Joannis Nov 3, 2025 •

edited

Loading

fabianfett Feb 3, 2026 •

edited

Loading