-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve usability of spawn
#29
Comments
Xtra had this, but this leads to cargo features being essentially broken. If two were enabled, then what would happen? This is why I changed it to take a spawner. Mutually exclusive features are generally not good practice with cargo because of how features enabled by different dependencies are unioned together. If, for instance, a library used xtra internally with
You should be able to just take |
I thought of one possible way to do this. There could be a trait SpawnGlobalTokioExt {
fn spawn_global(self) -> Address<Self> {
self.create().spawn(&mut Tokio::Global)
}
} Then, you would |
@Restioson I'd have to pass-through the let a: Address<MyActor> = MyActor::from_registry().await; would become: let a: Address<MyActor> = MyActor::from_registry(&mut AsyncStd).await; It's not terribly bad, but on the other hand would tie the code towards one specific async runtime. |
@Restioson Your suggestion would not really help much, as my library would still need to I think the main issue is that multiple runtimes can co-exist via the feature flags. IMHO, this does not make much sense. I just tried to compile
|
It would need to use it yes. That would only be one line though, and save space for all the I don't really want to go the sqlx compile error route here, as it still can break with cargo and dependencies as I described |
That's perfectly fine for me. I can live with that. Would there be a |
Yea, that's the idea. Each runtime would get a {Runtime}SpawnGlobalExt trait. Then, if you could use xtra::spawner::RuntimeNameSpawnGlobalExt;
x.spawn_global();
// ...
y.spawn_global();
// ...
z.spawn_global(); and save few characters over each doing |
That looks great! I'd then simply add |
Hi, could you test out the Also, the recommended way of writing a library with xtra would be to take the spawner as a parameter where possible, and then pass it to |
Please let me know if there is any interest in the functionality contained in the |
I'd love to see something like
spawn_default
which would use a sensible default Spawner depending on the configured cargofeature
. For async-std, this would default tospawn(&mut AsyncStd)
.Having a default spawner makes extensions easier. See my
xtra-addons
crate, which implements aRegistry
. The registry needs to be able to spawn a new actor, so that you can just typeMyActor::from_registry
(xactor has the same feature ;-). But spawning a new actor depends on the runtime, so that I have to provide an implementation myself (that's why I only support async-std atm).If you like to have this feature, I am willing to implement.
The text was updated successfully, but these errors were encountered: