Crate ratio_reactor

Ratio Reactor contains several structs and traits to quickly set up a queueing job shop reactors with different queuing strategies and means of keeping track of the reactor’s status.

What is a Reactor?

What does a reactor do? A reactor is a bi-directional WebWorker implementation that can send and receive messages and perform actions off of the main thread in your browser. Or in yew-agent’s terms:

A kind of agent that can send many inputs and receive many outputs over a single bridge.

Which means you can depend on the outputs of such a worker in your frontend, too!

Why queueing strategies?

A typical workflow would be to write your Yew app as usual, but implement certain heavy tasks in a WebWorker. You might want to just do “calculate-thing” as a “oneshot” that updates your state, but what happens when you fire many such messages shortly after each other? Which call or result is “the boss”? What is returned and should you update the UI for every call?

And what if you would like to know what your worker’s status is display that in your app? Is the worker busy? How busy? Many jobs waiting or just a single one? Can you categorize jobs, too?

Queueing strategies

The following strategies are supported as of now:

• FIFO queue
  • All jobs are executed in the order of arrival
• Skip waiting
  • New jobs that arrive while executing replace any waiting job
• Immediate switching
  • Quit current job on new arrival and work on that

Categorized keys

Both the FIFO and skip queue support “categorized keys”, meaning that you can apply these strategies “in-parallel” for different kinds of jobs and priorities. Code execution won’t be truly parallel per-se, but the reactor will keep a record of the strategy for each unique key such that all jobs tagged with a certain key follow the proposed strategy independent from each other.

The provided implementations of these keyed queueing strategies make use of the BTreeMap which results in “prioritized” categories, where the first key (i.e. the keys are sorted by their Ord and not by insertion order) has the highest priority and will be processed first.

Examples

For examples, please take a look at the ones in the GitLab repository

Modules

• fifo
  FIFO queue implementations.
• immediate
  Immediate switching queue implementation.
• key
  Module providing the KeyedData struct.
• poll
  Module providing the default polling duration struct.
• reactor
  Reactor module providing the Reactor struct as well as all traits to configure it.
• skip
  Skip-waiting queue implementations.
• status
  Queue status implementations.