Task Chain

[the-moisrex]

Task Chains are an idea for the Event Manager idea. They represent a chain of task/io-operations/events that will be passed to the execution context and the execution context starts to run them and handle with the errors.

Types of tasks:

• [ ] Any callables
  • [ ] Free functions
  • [ ] Classes with operator()
  • [ ] std::function, istl::function_ref, ...
  • [ ] Anything that can be converted to one of the above objects with taskify(...) function
• [ ] I/O Operations
• [ ] Coroutine Awaitable
• [ ] Possibility of P2300 operations
• [ ] Events
  • [ ] Library Standard Events
  • [ ] Custom User Provided Events
• [ ] Timers
• [ ] Another Chain: so an operation like read_file and return a chain of open >> read | handle_error and we can simply append those to the chain.
  • [ ] Should we have sub-chains or appending works better?

Features:

• [ ] Coroutines support
• [ ] Possibility of supporting P2300 proposal
• [ ] Extensible by creating new commands and operations

Other usages:

• [ ] Triggering the events through:
  • [ ] CLI
  • [ ] Inside Application itself to provide APIs and what not

Chains:

• [ ] operator >>: sequence an operation
• [ ] operator |: sequence an error handling operation
• [ ] operator &: sequence a finally operation that runs whether or not the chain was success or an error
• [ ] operator (): call the next task in sequence and schedule the next I/O operation if there's any; Required Arguments:
  • [ ] A reference to the Chain itself so we can:
  • [ ] chain.set_error(...)
  • [ ] chain.set_success(...)

[the-moisrex]

yielding can be just an iterator

[the-moisrex]

But what would be a consumer, if the yielder is an iterator?

[the-moisrex]

Another question:

How we should pass the yeilded value to the consumer?

• Pass the value
• Pass the iterator so the consumer can iterate at will
• Pass the previous task itself

[the-moisrex]

Idea:

• Producers are Iterables
• Consumers take Iterators
• Question: How does the execution context play into this scenario?
• Question: How can a producer and a consumer be one?

[the-moisrex]

• operator()(begin, end): consumer
• operator()(value): consumer
• operator()(): single shot producer
• begin(), end(): multi shot producer

[the-moisrex]

TaskChain

• final returned value can be void or not void; if it's not void, it's ignored in the execution context

Task

• Moveable
• constexpr

TaskState (Not-Iterator)

• returns no value
• the values are gone into task chains immediately

Dynamic Task State

• Can be used in response::body to hold a chain of tasks the return a body
• Gets attached (chained) to a "write" to socket eventually, then it's run

Execution Context (can it be an special TaskState?)

• Stores a list of TaskStates (not Tasks)
• Gets either a Task (and runs it immediately to get a TaskState) or a TaskState as input.
• Goes through each TaskStates and run an iteration on each of them until the TaskStates indicate that they're done

[the-moisrex]

• [ ] How to specialize I/O async tasks
  • [ ] Linking Requests in io_uring
• [ ] In io_uring we can setup multiple requests and then submit them once; how can that be done in these ideas? or even in senders and receivers?
• [ ] Fixed Buffers in io_uring???

[the-moisrex]

idea:

what if instead of taking a scheduler or something a-like as the first input of the algorithms, we take an operation state?

• [ ] How does the operation state gets constructed?
  • [ ] by calling connect on the task/task-chain
  • [ ] How would the task chain's connect look like?

Operation State requirements:

• [ ] Getting the next sub-task
• [ ] Getting the previous tasks so we can call get_value on them
• [ ] Having access to the execution context
  • [ ] For Halting purposes (putting the task chain in idle mode until some other task wakes it up)

[the-moisrex]

idea:

Each task would get an Operation State Token which is a kinda-pointer to the real deal and whoever (of the execution contexts) has it owns the operation.

So when a syscall is made into the io execution context, we pass the token as a callback; then the io execution context either

• calls the token to continue execution it the io execution context, or
• passes the execution context to the parent execution context (somehow), or
• passes it to the execution context that the token itself points to.