Skip to content
This repository has been archived by the owner on Oct 30, 2019. It is now read-only.

default cross-platform runtime #72

Closed
tamird opened this issue Jul 24, 2019 · 5 comments
Closed

default cross-platform runtime #72

tamird opened this issue Jul 24, 2019 · 5 comments

Comments

@tamird
Copy link

tamird commented Jul 24, 2019

This is a neat project! Over in Fuchsia we'd like to use this to abstract over unix/fuchsia async primitives. In particular, we would like to be able to run third party tests on fuchsia to validate that things work as expected in the presence of the (substantially) different underlying system.

As a motivating example, consider Trust-DNS, which has tests which need an executor because they deal in futures. In order for that code to compile on fuchsia, we need some executor implementation that is cross-platform.

Has any thought been given to how such a thing would be provided? Fuchsia is still substantially unstable, so adding a dependency from runtime to some Fuchsia crate wouldn't work (since we're not yet publishing our crates to avoid stability guarantees).

Thanks!

@yoshuawuyts
Copy link
Collaborator

@tamird hey, thanks for opening this issue! We'd love to have a working Fuschia target available by default in Runtime! But like you're saying, that doesn't quite seem possible right now. So what seems to be the clearest path forward would be if to create a new Runtime built specifically for Fuschia out of the Runtime tree.

The way to do that is to implement the traits in runtime-raw, and then it can be used directly from runtime as:

#[runtime(runtime_fuschia::Fuschia)]
fn main () {
    // code will work as expected here
}

The biggest gotcha of the runtime-raw traits is that the constructors live in the root trait, apart from their actual implementations. This is because of a current constraint in the trait object system. But aside from that I suspect it should be reasonably straight forward to abstract over.

Hopefully this was helpful; good luck!

@tamird
Copy link
Author

tamird commented Jul 29, 2019

Thanks for the reply, @yoshuawuyts! Implementing a fuchsia runtime does seem reasonably straightforward.

The bigger concern that prompted me to open this issue is the desire to have a way to write user code (i.e. Trust-DNS) which doesn't have to directly specify which runtime it uses, so that e.g. its tests can be platform-agnostic. Is that something to which any thought has been given?

@yoshuawuyts
Copy link
Collaborator

Ah sorry, it seems like I misunderstood what you meant!

The overarching answer here is to do what Rust's stdlib does, and create components that work on all platforms. But you're right that we probably shouldn't build in Fuschia support to Runtime's default runtime quiet yet.

What I'd suggest doing instead is still build out runtime-fuschia, but then use runtime-native from inside the library as a fallback for non-fuschia platforms. So if, say, trustdns wants to have cross-platform tests they could switch to use #[runtime::test(runtime_fuschia::Fuschia)] and it'd work on all platforms.

Does this better answer your question?

@tamird
Copy link
Author

tamird commented Jul 29, 2019

Sort of. That approach implies a dependency edge from trustdns to runtime-fuchsia, but that fuchsia crate is infeasible to publish for the same reason that such a crate can't be included in runtime itself. Did I understand you correctly?

@yoshuawuyts
Copy link
Collaborator

yoshuawuyts commented Jul 29, 2019

@tamird ah yes, you understood me correctly. That's.. unfortunate though. It almost sounds like we should have some sort of LD_PRELOAD method of loading dependencies, but that's quite a while out (almost seems related to std aware cargo, but like for external crates).

If there's a constraint on not being able to publish the Fuschia runtime as any code then the only other alternative I see is pulling trustdns into the Fuschia source itself, and adding a floating patch to switch out the runtime in-tree. But I'm guessing that's probably already been considered.

I'm sorry, I'm not sure what the best approach here would be.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants