Tightening the bind with IO manager

We want the fastest possible path between IO manager and xchars.  All binary.

IO manager will set aside a portion of args list, at the top of the last args list segment.  It can do this by adjusting he args heap index, which doesn't yet exist.  Regardless of any other activity, an encroachment within the args heap pointer is an error, a reset. All this easy code to add, few lines at most. It relies on  good management of args list by the snippets, or console loop burps.

IO manager, running on multiple threads can do this over multiple segments of args list, and the reserved args heap becomes shared memory with, most likely, xchars and one of the syntax engines. Likely the fastest message loop out there,once up and running.  If IO manager ever needs a redraw or rescale of a win, no problem, it calls xchars entry point directly, executes the redraw in complete binary, due to shared memory. It does no even need to set up the call, it has mapped whatever structured data it needs onto args already.  Remember args is the unified type, a 46 bit  thing all unto itself, and args list provides a near infinite array of them and a universal interface made of them.

Add rendering engine in client address space, the bus becomes a reconfigurable  gaming system. 

A protocol over IO manager to emulate the iPythoin notebook is entirely reasonable, one rectangle executing one script, the other another and the shred args list allows them to swap universal 64 bit things. Each rectangle can be a thread, rectangles can have mutex built ins. That notebook idea is truly a great one, the rectangle model with fonts only is a perfect fit.


Like a requantization of the layering results from the latest Moore.s law enhancements, all the layers shift one rank up.  Distributions like Void linux and other small embedded forms are appearing to act as intelligent processors, unto themselves. The bus concept is a natural, it would have appeared on one form or the other.