tokio
tokio copied to clipboard
tokio-rs
Adding support for QNX OS
This enables tokio to be used on QNX. It also depends on
https://github.com/tokio-rs/mio/pull/1766
@AkhilTThomas I added you to the fork, so you can write there as well
The changes are rather trivial, the main thing is a i32/u32 type mismatch that is handled
Not so sure what is expected/can done in terms of testing, as I assume there are no QNX machines in CI? What are the expectations here?
Once this is in acceptable form, would we need to backport it on one of the many version branches? As just tokio users we would appreciate some form of QNX support being available out of the box on released tokio versions, (even if would be hidden behind a "here be dragons, we have no idea what this does" kind-of flag )
Thanks for the PR. On the assumption that the mio PR is merged, then I am happy to add it here as well.
Once this is in acceptable form, would we need to backport it on one of the many version branches?
No, it will just go in with the next minor release and be available starting from Tokio v1.37 (or later depending on timing). Unlike mio, we don't have multiple supported major versions.
Not so sure what is expected/can done in terms of testing, as I assume there are no QNX machines in CI? What are the expectations here?
Adding support in CI is preferred but not required. Often, cargo check is possible even if there are no QNX machines in CI if we use cross-compilation.
(even if would be hidden behind a "here be dragons, we have no idea what this does" kind-of flag )
Tokio has a list of platforms with guaranteed support and a bunch of other platforms we support on a best-effort basis. This will not be something we guarantee ongoing support for, but I do not mind adding it.
Running test suite would need https://github.com/nix-rust/nix/pull/2055 not a blocker now for "best effort" QNX support, but preferably should be solved
Hi, Nix maintainer here, that Nix PR wasn't merged because we think it might not be worth considering how small the user group is, but if tokio wants this target support and it is blocked by that Nix PR, then I am willing to merge it.
That's needed to compile the test-suite, but would it actually enable us to run the tests? Can we run this OS in CI?
Hi @Darksonn : Yes, it would enable to compile, run tests. Which is good. Running all this in CI seems more complicated, see also my comment on mio https://github.com/tokio-rs/mio/pull/1766#issuecomment-2029037996
Again, as QNX users we appreciate everything that moves QNX support a bit closer to be on-par with other Tier 1 targets, but there is still some way to go. How far individual projects are willing to go to support this -for now- niche target is of course up to the communities. First step would be having some "not guaranteed to work/best effort code", that gives some amount of out-of -the-box functionality. Obviously, for all users it would be good to be able to run the test suite at least locally, especially since CI testing might still be a slightly harder nut to crack.
This has been merged for mio. Any updates on the PR for Tokio?
Hi @Darksonn We are waiting for the merge of the nix fix and one on the signal-hook-registry as well.
Is there a link to the signal-hook-registry change?
Unfortunately not yet, its stuck with an internal clearance 😢. But its a one liner with a suppression for SA_RESTART being unavailable for nto target.
Is there a link to the signal-hook-registry change?
Unfortunately not yet, its stuck with an internal clearance 😢.
That it was, it isn't anymore https://github.com/vorner/signal-hook/pull/158
Any updates here? I'm okay with merging it before it goes into other dependencies, since the change is so small. (But I do have a pending change request.)
Hi, it is not forgotten. May take a few days before sitting at a suitable computer. Just to be sure, the change you are referring is the shorter/ more "elegant" way of doing the id as i32;, right?