Architecture For Referencing And Interacting Tasks Around

⚓ Rust 📅 2026-03-25 👤 surdeus 👁️ 4

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Architecture For Referencing And Interacting Tasks Around

I’m posting here because we’ve been stuck on this for a long time. This is on behalf of McBrincie212—we couldn’t get any help on the Rust Discord, so I’m posting it here instead.

Summary

Currently im faced with a problem i've been battling for 2 weeks straight. In my system i have "Tasks" which contains their own TaskFrame, TaskTrigger and TaskHooks (a collection of them). Then i have "Schedulers" which are meant to own Tasks, the problem im faced goes as follows:

"How do I interact with the Task in outside code without holding anything related to the "Scheduler" everywhere, only the identification part of the Task."

For example, suppose a TaskDependency may want to inject its own TaskHooks, hence needs a way to communicate with the Task. Another example is suppose AlertTaskHook may want to fully remove a Task when it sees something... etc.

I have come up with two solutions:

Task / IDs Users assemble a Task<T1, T2> struct where T1 and T2 is the TaskFrame and TaskTrigger respectively. Then you can reference around via &Task<...> before being scheduled but when you need to schedule it on a Scheduler you need the owned part, then it returns an identifier helping you to reference it back via the Scheduler (the identifier is clonable).
- [✓] Simple to implement from my side (macros and TaskFrameContext)
- [✗] Two different APIs for the same thing
- [✗] During the identifier API, you must leak the Scheduler which owns this Task as well which is a bad pattern
- [✗] Assumes a specific storage shape mapping an ID to a Task (no flexibility)
TaskHandles Its a similar idea to the above, but the difference is you explicitly tell the Scheduler, the TaskFrame and TaskTrigger to allocate into a Task, then it returns a handle containing the location of the Task along with methods for interacting with it (including Scheduler-based operations).
- [✓] Flexibility in how the storage layout is defined
- [✓] One unified API
- [✗] Difficulty in implementing the macros and TaskFrameContext

The issue:

github.com/GitBrincie212/ChronoGrapher

[ARCH] Rethinking ``Tasks`` And Referencing Them Elsewhere

opened 09:44PM - 13 Mar 26 UTC

GitBrincie212

Enhancement Help Needed Refactoring Architectural Core System Difficulty: Hard Planning

**What area has an architectural problem? Please describe.** The ``Task`` area s…pecifically allocating ``Tasks`` to the ``Scheduler`` and referencing them elsewhere. **Why does this area have this architectural problem?** Currently the ``Task`` system is messy at best, creating a ``Task`` involves two ``Arc<T>`` allocations for the ``TaskFrame`` and ``TaskTrigger`` respectively, and to top it all off, currently the ``EphemeralTaskStore`` wraps an additional ``Arc<T>`` on top of the entire ``Task`` causing a total of 3 ``Arc<T>`` to be used per Task. In addition to the ineffecient memory layout (and runtime due to atomic increments), ``Task`` can also be erased via its ``.as_erased()``, this is used in the Scheduler mostly for handling a collection of those Tasks. The problem is its a code smell more than anything and can definitely be improved upon. **Describe the solution you'd like** Currently there isn't a good solution to go by, this is an issue up to debate on which approach is best. However few key characteristics the new ``Task`` system should include ideally: - Avoid most of the ``Arc<T>``, if unavoidable then use at least one. - Allow ``Task`` instances to be shared / borrowed around (the ``Scheduler`` owns the Task) easily in a cheap way. This borrow should include ways to getting the ``TaskFrame``, ``TaskTrigger`` and allow attachement, detachement or getting``TaskHooks`` and even emitting them. - Allow removal of a ``Task`` which subsequently the references will do nothing or return ``None`` perhaps? The idea is to allow removal of a ``Task`` in a memory safe way. **Describe alternatives you've considered** One solution i tried is a handle-based approach which the ``SchedulerTaskStore`` has a ``create`` method accepting the ``TaskTrigger`` and ``TaskFrame``. Internally the ``SchedulerTaskStore`` allocates a Task onto itself and returns a typed handle which allows accessing the ``TaskTrigger`` and ``TaskFrame`` (without the need of being erased). Additionally the handles were cloneable and allowed for communicating with the ``Scheduler`` just like ``SchedulerHandle`` for halting, blocking, executing and rescheduling. The difficult part however is it introduces severe complexity, its hard to create a handle in the first place while allocating a ``Task`` owning the ``TaskFrame`` and ``TaskTrigger``, it does make it more difficult for object-safe code to be defined and many other issues.

Before writing a full explanation about the problem and any clarifications. Do let me know first if anyone is willing to help out with the problem (as to not write an entire manifesto and waste time from ignorance). For the gh issue its not too suffecient to explain everything so if you have any questions, again let me know 100% predicting no one will be interested to help either from the get go or after the full explanation

2 posts - 2 participants

Read full topic

🏷️ Rust_feed

👍 󠁮󠁮󠁮󠁮 👎 󠁮󠁮󠁮󠁮