# \[PITCH\] io\_uring support in Swift System on Linux **URL:** \ **Category:** Pitches\ **Tags:** linux, server, io, swift-system\ **Created:** [March 6, 2025, 8:23pm UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340 "2025-03-06T20:23:06Z")\ **Posts on this page:** 9\ **Page:** 2
**Author:** ![lukeh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukeh/32/31648_2.png) [@lukeh](https://forums.swift.org/u/lukeh)\ **Post date:** [March 7, 2025, 10:07pm UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/21 "2025-03-07T22:07:51Z")
Yes, it was a recent revelation to me that polling can be more efficient than interrupts in some cases. ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [March 8, 2025, 11:07am UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/22 "2025-03-08T11:07:48Z")
This is more meta level but this pitch is one of the first ones where we could use [package traits](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0450-swiftpm-package-traits.md). I was thinking about how we could integrate this into `swift-nio` while making sure that the APIs are working in practice. It is quite common that we need to do small tweaks to the API after integrating it and it getting the first production usage. One use-case for package traits is modeling experimental features across packages. We could put the new io\_uring APIs behind an `ExperimentalIOUring` trait in `swift-system`. `swift-nio` could then redefine the same trait and conditionally enable `swift-system`s trait. This would give us some time to land the feature across the ecosystem and stabilize it before we have to fully commit to the API. ---
**Author:** ![lukeh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukeh/32/31648_2.png) [@lukeh](https://forums.swift.org/u/lukeh)\ **Post date:** [March 9, 2025, 12:48am UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/23 "2025-03-09T00:48:20Z")
The other thing I would suggest is, should it be in Swift System if thereā€™s no Darwin support? ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [March 9, 2025, 1:35am UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/24 "2025-03-09T01:35:10Z")
Despite its name, Swift System has been designated the place for OS-specific APIs, not universal abstractions. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [March 10, 2025, 2:11pm UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/25 "2025-03-10T14:11:08Z")
> [@Jon\_Shier](#): > > Despite its name, Swift System has been designated the place for OS-specific APIs, not universal abstractions. Right, though I'm somewhat confused by "despite its name". Swift System's purpose is to provide **swift** bindings for host **system** semantics. Hence, "Swift System". šŸ˜ ---
**Author:** ![David\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_smith/32/37508_2.png) [@David\_Smith](https://forums.swift.org/u/David_Smith)\ **Post date:** [April 4, 2025, 11:57pm UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/26 "2025-04-04T23:57:57Z")
I've pushed an update to the pitch with a number of changes discussed here. There's a few odds and ends I want to tie up before putting up a second pitch, but for anyone curious: - IOResource is a struct now, it turns out that works just as well; it doesn't fix the lifetime issues, but it's no worse than a class and better in other ways - "ing" names dropped - Cancellation operations added. I investigated the Rust versions of this, and I agree with them in principle, but I don't see a way to implement that sort of thing without being a very different type of API than we're currently proposing. - Features is an OptionSet now - Various smaller fixes like adding `throws` to a few operations that can fail I have not, yet, addressed the following things I'm aware of from the thread that I'd like to get to before posting a new pitch, hopefully next week: - IORING\_SETUP\_SQPOLL, IOSQE\_CQE\_SKIP\_SUCCESS, IORING\_ATTACH\_WQ, and other handy setup flags - Fleshing out the set of supported operations somewhat further - Perhaps some additional examples - Ideally, figuring out how to make the context/user\_data system more ergonomic to use I also haven't addressed, and don't plan to address (in this proposal) the tension between "expose io\_uring in Swift", and "design a Swifty API for async IO, using io\_uring". This proposal is the former, which automatically excludes a number of ideas that we might be able to do if we were more "opinionated" about how to use the underlying primitives. I do want to take another glance over ringbahn and make sure I'm not missing something we can use, but so far what I'm seeing is more in the "opinionated abstraction" camp, albeit a very clever low overhead version of such. ---
**Author:** ![David\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_smith/32/37508_2.png) [@David\_Smith](https://forums.swift.org/u/David_Smith)\ **Post date:** [April 17, 2025, 11:55pm UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/27 "2025-04-17T23:55:21Z")
Opinion question for y'all: I'm working on fleshing out the error handling story, and my initial approach was a couple of nested error structs for setup, resource registration, and operationsā€¦ but I'm realizing that with an interface like this, throwing Errno might make just as much sense and be more consistent with other operations. Thoughts? Also: after getting pulled away from this for a bit I'm back on it, and pretty much only blocked by a compiler crash I ran into that I'm still trying to find a workaround for. ---
**Author:** ![lukeh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukeh/32/31648_2.png) [@lukeh](https://forums.swift.org/u/lukeh)\ **Post date:** [April 18, 2025, 7:51am UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/28 "2025-04-18T07:51:52Z")
Using `Errno` from `swift-system` makes sense to me and is what I did in IORingSwift. ---
**Author:** ![lukeh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukeh/32/31648_2.png) [@lukeh](https://forums.swift.org/u/lukeh)\ **Post date:** [April 18, 2025, 7:52am UTC](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340/29 "2025-04-18T07:52:14Z")
> [@David\_Smith](#): > > I also haven't addressed, and don't plan to address (in this proposal) the tension between "expose io\_uring in Swift", and "design a Swifty API for async IO, using io\_uring". This proposal is the former, which automatically excludes a number of ideas that we might be able to do if we were more "opinionated" about how to use the underlying primitives. That's good to hear. Perhaps I can migrate IORingSwift to use your library. [Previous page](https://forums.swift.org/t/pitch-io-uring-support-in-swift-system-on-linux/78340.md?page=1)