You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The scheduler for component lifecycles currently pushes boxed runners into the queue, incurring an allocation. A stable memory allocation is already available, in the form of a Rc<ComponentState> for each component. This could be used to store the pending lifecycle events similar to the MsgQueue that was introduced as part of #2421. An implementation should not re-introduce the generics that were removed as part of that PR.
Hi, interested in picking this up, which solution should be preferred?
Replace Box<dyn Runnable> in scheduler with enum Task which would contain task kind, Rc<ComponentState> and relevant data and matched runners for each Task variant.
Replace scheduler queues with a main one with Rc<ComponentState>, where the ComponentState would contain a queue of tasks to be done on the component. This would though remove the scheduling depending on the task kind which is now present
Hi, interested in picking this up, which solution should be preferred?
1. Replace `Box<dyn Runnable>` in scheduler with enum `Task` which would contain task kind, `Rc<ComponentState>` and relevant data and matched runners for each `Task` variant.
2. Replace scheduler queues with a main one with `Rc<ComponentState>`, where the ComponentState would contain a queue of tasks to be done on the component. This would though remove the scheduling depending on the task kind which is now present
The different task queues should be retained and run in the same order. Note that each task queue, except for create (generic over COMP) and main (for user tasks) contains only a single type of task, hence Boxing those is unnecessary.
Since I opened the issue, the implementation has changed a bit. Most impls then were generic in the type of BaseComponent like CreateRunner still is. Now, runners such as UpdateRunner are monomorphized, so the easiest solution is to e.g. replace destroy: Vec<Box<dyn Runnable>> with destroy: Vec<DestroyRunner>. Bonus points if you find a way to get rid of the generic argument in CreateRunner without adding more allocations, I think this should be possible, but might be a bit more fiddly.
Suggestion
The scheduler for component lifecycles currently pushes boxed runners into the queue, incurring an allocation. A stable memory allocation is already available, in the form of a
Rc<ComponentState>
for each component. This could be used to store the pending lifecycle events similar to theMsgQueue
that was introduced as part of #2421. An implementation should not re-introduce the generics that were removed as part of that PR.See also: #2330 (comment)
Questionnaire
The text was updated successfully, but these errors were encountered: