swift-nio
swift-nio copied to clipboard
apple
Provide NonBlockingFileIO helpers that use Swift System
As Swift System has gone 1.0 we can in principle take a dependency on the package. This might be a good opportunity to clean up NonBlockingFileIO abstraction to be rewritten in terms of Swift System's public types.
@Lukasa I played around with this yesterday evening and had a question.
Are we thinking that we would preserve the current NonBlockingFileIO API surface as it currently is today, and just change the implementation detail under the hood, or would we want to deprecate the current API in favour of something new?
Assuming the need to preserve API, I found I needed to translate the System.Errno errors back into NIO's NonBlockingFileIO.Error.descriptorSetToNonBlocking and IOError types. After this, the various read and write APIs seem to satisfy the existing tests.
The potential gotcha here is the lack of an ftruncate equivalent in Swift System, unless I'm missing something?
I think we'd ideally keep the existing API around for now, where we can, but we'd also want to add new API surface that consumes the types from swift-system as well. We can definitely then deprecate the older API in favour of the new one.
As for a missing ftruncate, that is something we should follow-up on with swift-system.
OK, I have a patch for Swift System to add a new API to Swift System for ftruncate functionality, I'll open a PR when I can.
OK, I have a patch for Swift System to add a new API to Swift System for
ftruncatefunctionality, I'll open a PR when I can.
https://github.com/apple/swift-system/pull/82
@simonjbeaumont / @Lukasa what are the thoughts w.r.t. Swift System having an OS-dependent API?
At the moment I think I'm most interested in going to the higher level API surface, but in general I don't think it should matter overmuch.