The idea is pretty simple, lets imagine.

* A single sequence of code (like a single threaded program).
Code is discrete functionality.
It is the change of some state(s) of electric circuits.
Code is usualy IOing or working on a context which is basically data.
Lets forget the IOing for today.


* Then cut it into functional pieces which are defined by doing exactly one certain change on the context data.
A tick is the piece of functionality neccessary to do a specified change of state/information/data.
For example, the classic clock has three ticks which contain the movement of one of three arrows by 360°/12, 360°/60 and 360°/60 or in short how the projected time(piece of data) is modified. The joke is, its ticking(discrete functionality) abstracts continuous functionality of the clockwork.

* The combination of a set of tick(s) acting on certain data is an entity.

* The question for realizing complexity is, how to change context in a sequence of ticks which need to act on multiple data. And here we go biology.
A cell in your body is basically a thing getting a signal and doing something within its own system.
This something could also be triggering functionality to send a signal to another cell.
So Tick, Tick, Signal, Tick, Tick, Tick, Signal, Tick, Signal and so on.

* Entities are abstractable.
A cell has its contained functionality acting on its contained information.
You sum many cells up and you get a human entity containing more functionality acting on more (contained) information.

* These entities are arranged in spaces which are an abstraction.
You could compare them with organs.

* When an entity gets a signal, it triggeres a tick.
In my realization A tick can decide if it accepts.

* A tick can trigger one or more further ticks or send a signal.
And they can act on the entities context data.
Practiacally synced by a read/write mutex.

* Ticks are enqueued in a TaskPool with n threads.
Since multiple signals can trigger ticks at a time, you get a perfect non linear system using n threads for computation of multiple strains of discrete causality.

* Yes, load balancing by design.
The challange here is to minimize the times threads spend locked, so you can use as much cputime as possible... if you have to.

* Entities building complexes are organized in spaces having a domain name.

My problem:

Signaling is the big variable in this.
A signal can block and return bool(accepted) or simply send the request out async and return void.

A signal can address
* one certain entity listening to that signal type inside its own space
* any listening to that signal type inside own space but only one in total
* all listening to that signal type inside own space
* one certain entity listening in a certain space
* all listening in a pattern matching space like xyz.abc.* (bad idea as blocking)
* any listening in a pattern matching space like xyz.abc.* but only one in total (bad idea at all I think)

Within a space there is no problem except a fitting naming. Actually (taken from tcp/ip) unicast(blocking), anycast(blocking) and multicast(nonblocking).

Outside its more complicated. Outside could even mean on mars. So blocking seems to be a bad idea at all... or for certain cases not?
I could imagine people having such complexes connected with others over the internet might raise security concerns if transport is not clearly, predictive and KISS designed.
Things which should not happen should be excluded by design, but what is it what should not happen in such a system?
What would be the hack?

The code https://github.com/RalphBariz/flow/tree/rework
(actual dev branch, docu is outdated but basically informative)

BR
Ralph