The New(?) Architecture of Redisplay

I came across recently an email message on Tweak (a GUI for Squeak Smalltalk) and display refreshes in the presence of asynchronous processes...

So why not use processes?! Looking back at some older conversation about using multiple processes it appears to me that we've been holding back on it because of synchronization issues. While this is certainly understandable (we all know how hard process synchronization can be) I think that we can solve this problem in a very simple way that gives us the best of all worlds.

Here it is:

The basic problem that we have when using multiple processes is that we can't always say for sure when they are run. Because of this, the system may activate some process while we're in the midst of redrawing the screen, handling events, executing some (interfering) other process etc.

Yes, to multiple processes.

I developed some CAD tools a couple different times way back when, that had to deal with distributed processes and asynchronous messages. More recently, but still seven years ago (dear lord, really!) I developed an example graphics editor in Erlang and Tk. Today I would approach an intraprocess design the same as the distributed. First and foremost -- get rid of shared memory and the synchronization issues go way down. Synchronization becomes a design tool rather than an accident waiting to be found, or a burden of self-over-protection.

Here's the real news... there is a *lot* to learn from understanding how Emacs works.

Emacs got the architecture of asynchronous redisplay right 25-30 years ago when it was dealing with the asynchronous nature of text redisplay in the presence of asynchronous keyboard interrupts. The "command pattern" and graphics, etc. are just elaborations on the theme.

Another thing Emacs got right is keyboard maps from keys to functions. A "mode" is a more or less different map from keys to functions. A "modal dialog" is just pushing a new mode map into the keyboard process for some period of time. Emacs embodies a pretty good "model-view-controller" separation.

Processes and display refresh -- expand the Emacs way into true multi-processing. One process owns a display device. Other processes, local or otherwise, may be able to send it display update events. Those messages may have priorities, or rather the display process may understand which collaborators have priorities.

The display process will always try to process the most important update message next. Display update may be postponed until some or all update messages have been processed. If there is a hope of getting through the message queue in time, then the display process will postpone a refresh until the queue is empty, otherwise some logic of when to stop postponing the refresh has to be coded.