This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
refactor the way tasks are scheduled in event-loop #8186
Labels
F6-refactor 📚
Code needs refactoring.
M4-core ⛓
Core client code / Rust.
P5-sometimesoon 🌲
Issue is worth doing soon.
Milestone
Comments
debris
added
F6-refactor 📚
Code needs refactoring.
P5-sometimesoon 🌲
Issue is worth doing soon.
M4-core ⛓
Core client code / Rust.
labels
Mar 22, 2018
Ideally the long-term plan would be to remove the current |
@debris Recently I was skimming through a blog post describing Actix API. Maybe we may use something similar. The key idea is that instead of huge enums messages and handlers may be defined as trait impls: use actix::prelude::*;
// `PlusOne` message implementation
struct PlusOne;
impl Message for PlusOne {
type Result = u32;
}
// `CounterActor` implementation
struct CounterActor {
count: u32,
}
impl CounterActor {
pub fn new() -> CounterActor {
CounterActor { count: 0 }
}
}
impl Actor for CounterActor {
type Context = Context<Self>;
}
impl Handler<PlusOne> for CounterActor {
type Result = u32;
fn handle(&mut self, _msg: PlusOne, _ctx: &mut Context<Self>) -> u32 {
self.count += 1;
self.count
}
} That way code would be organized more naturally. |
Closing the issue due to its stale state |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
F6-refactor 📚
Code needs refactoring.
M4-core ⛓
Core client code / Rust.
P5-sometimesoon 🌲
Issue is worth doing soon.
after #8185
Current design requires us to define all tasks types in a single place in
ClientIoMessage
. It makes it difficult to modularizeethcore
. Let's think how we could refactor that so tasks could be scheduled without the need of defining them in a single place.cc @tomaka @0x7CFE
The text was updated successfully, but these errors were encountered: