Introduce IOCP based AsyncIO for Windows #117
Conversation
- Darwin: based on DispatchIO - Linux: based on epoll - Windows (not included in this commit): based on IOCP with OVERLAPPED
- Darwin: based on DispatchIO - Linux: based on epoll - Windows (not included in this commit): based on IOCP with OVERLAPPED
|
Resolves: #110 |
|
Talked to @iCharlesHu offline and he confirmed that if we merge this one, we won't need #64 |
| // if another part of the code inadvertently reuses the same file descriptor | ||
| // number. This problem is especially concerning on Unix systems due to POSIX’s | ||
| // guarantee of using the lowest available file descriptor number, making reuse | ||
| // more probable. We use `fatalError` upon receiving `.badFileDescriptor` |
There was a problem hiding this comment.
nit: this comment still refers to the non-Windows path
| internal init(closeWhenDone: Bool, purpose: Purpose) throws { | ||
| #if canImport(WinSDK) | ||
| // On Windows, we need to create a named pipe | ||
| let pipeName = "\\\\.\\pipe\\subprocess-\(purpose)-\(Int.random(in: .min ..< .max))" |
There was a problem hiding this comment.
I would be a bit worried about running into collisions here, there is a good chance this could repeat and lead to subtle bugs. Instead of making it random, what about using a monotonically increasing unsigned 64-bit integer stored in a static variable? Then we can guarantee this is never a problem.
Something like this maybe?
func nextPipeNumber() -> UInt64 {
struct Static: ~Copyable {
static let pipeNumber = Atomic<UInt64>(0)
}
return Static.pipeNumber.add(1, ordering: .sequentiallyConsistent).newValue
}| nil | ||
| ) | ||
| // Wait for monitor thread to exit | ||
| WaitForSingleObject(monitorThreadHandle, INFINITE); |
| // Old registration found. This means this handle has | ||
| // already been registered. We simply need to update | ||
| // the continuation saved | ||
| storage[completionKey] = continuation |
There was a problem hiding this comment.
Are there scenarios where this is expected, and couldn't this leave continuations that never get resumed? Should this fatalError?
| // Get a pointer to the memory at the specified offset | ||
| // Windows ReadFile uses DWORD for target count, which means we can only | ||
| // read up to DWORD (aka UInt32) max. | ||
| let targetCount = min(bufferPointer.count - readLength, Int(UInt32.max)) |
There was a problem hiding this comment.
Swift also supports x86 (32-bit) Windows, Int(UInt32.max) will overflow and crash because Int is Int32 and not Int64 there.
| // Windows WriteFile uses DWORD for target count | ||
| // which means we can only write up to DWORD max | ||
| let remainingLength = min( | ||
| ptr.count - writtenLength, Int(DWORD.max) |
There was a problem hiding this comment.
Int(DWORD.max) will also crash on x86-32. There's a few more occurrences of this later in the file as well.
This PR finishes
AsyncIOby introducing Windows IO Completion Port based implementation.This PR is staged on top of #64 and should be considered ready to be review as soon as that one lands.