-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Task executor extension for runtime host #5249
Conversation
primitives/externalities/src/lib.rs
Outdated
/// Return handle that can spawn parallel tasks. | ||
/// | ||
/// Can be none if host does not support parallel tasks. | ||
fn spawn_handle(&self) -> Option<&dyn ClonableSpawn>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't want to add anymore functionality to Externalities
. This was the reason Extension
's where introduced. I know that extension handling is currently a bit shitty, but please make this an extension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me as Extension
as well, but just to note and as discussed: this Externalities
ability will be quite essential (modulo test implementations of it), while Extension
-s are optional and generally not required for code execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok after some more disussion with @kianenigma there is a strong indication that this functionality will need to be rather configurable, and Extension will definitely help to achieve configurability in much more convenient way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mot notably, if we can configure the child threads (or whatever we call them in this context) to not be able to write to storage and instead return the buffer changes, this will give us a big chunk of what we need for transaction parallelism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bkchr updated!
7dfa665
to
2fa2411
Compare
I will squash / force push this pr, because it is used in another pr, so sorry about that |
2c8716f
to
a11fa28
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, few minor grumbles that I'm not super strong on.
@@ -212,3 +212,21 @@ impl CallInWasmExt { | |||
Self(Box::new(inner)) | |||
} | |||
} | |||
|
|||
/// Something that can spawn tasks and also can be cloned. | |||
pub trait CloneableSpawn: futures::task::Spawn + Send + Sync { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of traits that just describe the expected programatic behavior instead of some more high-level code idea.
Also this causes Box<dyn CloneableSpawn>
to be quite widespread.
Can't we have a struct
that will just wrap this? Like so:
#[derive(Clone)]
struct TaskExecutor(Arc<dyn futures::Task::Spawn + Send + Sync>);
impl TaskExecutor {
pub fn spawn(...) {}
}
We don't even need this extra trait cause it's in Arc
and I feel it avoids much of code repetition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've considered something like that. The problem is we won't be able to have special implementation of clone in task executor this way. It might require little more than just shared reference clone in use cases I think about.
@@ -70,6 +70,8 @@ mod changes_trie; | |||
#[cfg(feature = "std")] | |||
pub mod traits; | |||
pub mod testing; | |||
#[cfg(feature = "std")] | |||
pub mod tasks; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure this fits into sp-core
, but at the same time we don't really have a better place currently, so I'm fine with this (unless someone has a better idea where to put it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably could put everything tasks related (Also the CloneableSpawn
trait) in its own crate, but the current amount of code isn't also that much.
ebb37e7
to
2f61e79
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nitpicks, otherwise looks good.
// You should have received a copy of the GNU General Public License | ||
// along with Substrate. If not, see <http://www.gnu.org/licenses/>. | ||
|
||
//! Module for low-level asynchronous processing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this just providing a single threaded executor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, at the moment, yes
@@ -70,6 +70,8 @@ mod changes_trie; | |||
#[cfg(feature = "std")] | |||
pub mod traits; | |||
pub mod testing; | |||
#[cfg(feature = "std")] | |||
pub mod tasks; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably could put everything tasks related (Also the CloneableSpawn
trait) in its own crate, but the current amount of code isn't also that much.
2f61e79
to
ecee163
Compare
ecee163
to
a6a9e5c
Compare
This will essentially allow spawning tasks when handling host functions, using the main scheduler.
It is immediately needed for #5023, also for variant of #5023 for block production
And is generally useful in a sense that it will allow parallelise runtime execution (but should be used carefully and join spawned tasks deterministically - one-by-one / or in well-defined order if multiple are joined)