Wed Aug 19 11:33:46 EDT 2020

The condition to event spectrum

A little context: I have been exploring several multitasking scheduler

- Actor


- pull-FRP (redo)

- push-FRP

- conditions

These have a strong affinity to particular problem and solution
spaces.  By feel: Actor is for garbage collected languages doing
network things, and is fairly general.  CSP is a variant that maps
better to resource constrained problems.  FRP works well if the model
is somewhat physical, and condtions work well if the implementation is
hardware-like, e.g. dedicated gateware or a CPU loop.

The core implementation constraint boils down to events being
expensive at the low level, but cheap at the high level (once the
message API already exists).

The border here is the introduction of time-sharing: a CPU or
programmable datapath does more than one thing, v.s. dedicated
hardware polling a single function.

Right in the middle of the software complexity gradient is the
transition from no scheduler (just a poll loop), to an inverted
representation with events, tasks and the idea of using events to the
process of task scheduling.

Going up the ladder a bit more, there is the abstraction of memory: if
unbounded queues are a possibility, the Actor model can be

To rephrase: the availability of abstractions drastically change the
engineering landscape, and there is no one-size-fits-all.  From bottom
up, these are the world-changing abstractions:

- combinatorial logic

- async logic (flip-flop)

- clocked logic (clocked FF, RTL)

- programmable datapath, CPU

- software loop vs. scheduler

- memory abstractions

I think this settles the question: why are there so many different

This leaves the question: what does the semantic border between
round-robin condition polling and an evented scheduler look like?