swift-nio
swift-nio copied to clipboard
apple
NIOPosix: add import for `stderr` on Windows
Windows cannot directly access the standard error stream due to it being a "complex" macro according to the clang importer. This requires us to use the CRT Swift overlay wrappers to access the stream. Add the appropriate import.
Before we go down this road: is it worth making NIOPOSIX build on Windows? Would we be better served by simply abandoning it and building a NIOWindows instead? It's likely to be vastly less work.
Before we go down this road: is it worth making NIOPOSIX build on Windows? Would we be better served by simply abandoning it and building a NIOWindows instead? It's likely to be vastly less work.
This also jives with the stance of Swift System, where the Windows build has been broken a few times. The existing codebase has wrappers for all the POSIX functions and provides Windows implementations but there's now a drive to move away from this, as described in https://github.com/apple/swift-system/issues/94:
Never, ever, pretend that Windows implements POSIX system calls.
I think that it is worth going down this path. Ultimately, the dependencies percolate throughout the tooling (docc is a good example). Pushing the differences down means that a lot more work can be avoided in the downstream packages. Furthermore, if there are API differences, that only encourages further drift both at the NIO level as well as the consumers of it. In terms of what is unavailable, I think it comes down to non-blocking pipe IO, select (this is something that dispatch already dealt with), and perhaps the biggest item from the NIO perspective: sockets and pipes/files are different domains and CInt cannot represent both.
@simonjbeaumont - that only broke due to lack of testing (https://forums.swift.org/t/windows-pull-request-testing-support-on-swift-driver-and-swiftpm-repositories is a step in the right direction though!) Relying on a human to test each and every patch across everything is not a sustainable nor scalable solution.
While I agree that the dependencies percolate through the tooling, I don't forsee this as an issue. The tooling is free to build anything it wants, and that absolutely includes a variant of NIO for Windows. We have much of the functionality required already to ensure that this works properly (such that NIOPOSIX is not needed). I'm very reluctant to try to force Windows to fit into a POSIX-shaped hole, and I'd be utterly unwilling to include IOCP in NIOPOSIX.
If there is a way that you can ensure that the client is insulated from the differences, I'd be okay with a separate module.
The client cannot be completely insulated from the differences, but NIO already supports multiple kinds of EventLoops and Channels, and applications can handle it. For example, grpc-swift can use either NIOPOSIX or NIOTransportServices, and makes the choice when initialised. A similar approach could work for a NIOWindows/NIOIOCP equivalent.
If it is as you claim, a simple selection at initialization, that seems fine as long as there is something in NIO that ensures that any changes made in NIO will not cause the NIO clients to have an entirely separate path for each system.
grpc-swift and async-http-client already do this. Very little code is required to use alternative event loop and channel implementations.