Substrate: How to spawn a task in a task

[YaaMe]

Depends on commit https://github.com/paritytech/substrate/blob/2393e9b597e7fb2fccff574621eaccb8ab15db6d/core/service/src/lib.rs#L510-L515

and use it like
https://github.com/paritytech/substrate/blob/2393e9b597e7fb2fccff574621eaccb8ab15db6d/node/cli/src/service.rs#L127-L134

but how to handle

// service_package/src/lib
pub fn get_task(to_spawn_tx: XXX) -> Task {
    // other code
    to_spawn_tx.unbounded_send(another_task);
    // other code
    my_pack::get_task()
}
// node/cli/service
service.spawn_task(Box::new(my_package::get_task(
    service.to_spawn_tx.clone() // <- private now
)))

I think return instance self.to_spawn_tx.clone() is necessary....or any other suggestions?

[bkchr]

I don't understand your question? What do you want to achieve? A handle for spawning tasks?

[kigawas]

@bkchr
IMO he's trying to spawn a custom task, the way it spawning a task is to call self.to_spawn_tx.unbounded_send(task), but the self.to_spawn_tx is private so we cannot do it without changing substrate's code.

Is there something else we can do?

[bkchr]

And you can not call service.spawn_task()?

[YaaMe]

I want to inject a service layer with spawning some tasks.Depends on fn spawn_task.
the only way to handle it is like

service.spawn_task(Box::new(my_package::run_task(&service)));

1: service.to_spawn_tx is private
2: you couldn't clone service
3: how to define the service type in fn run_task(service: ?);
4: a bit wired..because package shouldn't touch service instance, just need bridge.

which seems not a good idea..

The another way to do this is bring them here

{
  // my other code
  service.spawn_task(my_task);
  // my other code
}

which seems worse...because it won't be a independent package any more..

[bkchr]

So, would this: https://github.com/paritytech/substrate/commit/2c06fb57ae11a73edc6374eacc3eb132526c8709 solve your problem?

If yes, I will make a pr out of it.

[YaaMe]

yep

[bkchr]

Okay, than give me moment :)

[bkchr]

Here is the pr:https://github.com/paritytech/substrate/pull/2992

[kigawas]

@bkchr So efficient! :rofl:

[tomaka]

I would strongly suggest refactoring the code to be poll-based instead, but I can't help much without looking at code.

[bkchr]

What you mean by poll-based?
If you send your future to service isn't it poll-based?