CMS by Drupal
My X Toolkit Plan
For a long time, I've been threatening to "work up the stack" from XCB. Indeed, this is behind many XCB design decisions. I want to eventually build apps on top of a framework designed bottom-up in a flexible manner.
This blog post describes my medium terms in this direction. By the way, this is a pretty different plan from what it was two months ago. This may mean that it's also different from what I'll eventually actually do. My mileage may vary…
Premise: Current toolkits (meaning practically everything) have lousy solutions to several important problems. As an example, let's imagine I'm going to build a chess program with an integrated GUI. Problems:
So what's my solution? Four phases—you've seen the first two already.
Specifically, phase III involves trying new architectures for X application structuring. My first candidate is based on these observations:
OK, enough blather. Here's my proposed toolkit architecture, version 0.
event thread ---> | | -> drawing thread | blackboard | -> other output one thread per -> | | threads other input | | ---------- | ^ v | application "engine"
It is important that all threads are completely lockless, block waiting for inputs ("pull model"), and communicate only via channels and the blackboard.
What's a "blackboard"? It's an architectural data structure idea that has been around, especially in AI circles, for 40 years, and IMHO has been grossly underutilized. Basically, a blackboard is a large data structure segmented into components. Applications can block waiting to be triggered by combinations of data appearing on the blackboard. They can also poll the blackboard, and post data to the blackboard. Thus, the blackboard fills simultaneous roles of synchronization/rendezvous of threads and data sharing.
(Mental exercise—60 seconds: What blackboard has been a stock part of the X Window System since the beginning, and is used much as above? [Note that this does not mean that I'm planning to use the existing thingy as a blackboard; we'll build a custom blackboard from scratch.])
The theory is that with blackboard and library magic, I can provide a library that makes the threads essentially invisible (as e.g. Java AWT/Swing does), but still prevents or detects common threading bugs. 1 above is taken care of trivially. 2 can be handled by not serializing or even by de-serializing where appropriate, and by getting rid of the locks, condition variables, shared structures etc that make thread programming hard. Debugging becomes much more fun, because you can stop one or more threads at any point and examine the blackboard to figure out what's going on. 3 is handled by the fact that there's no necessary or real correspondence between threads or objects in the program and objects on the screen; this allows much more flexibility in tackling 4 and 5 in Phase IV.
At least this is the current theory. It awaits time and/or volunteers to try building it out. Any comments are greatly appreciated.