[Openmcl-devel] debugging debugging

[Toomas Altosaar]

Most likely very few people are aware of this, but from around 
version 5.1b4 onwards, MCL offered a bona fide real-time environment 
in Lisp. Tens of cooperative threads (processes) could run in 
"parallel" (time-sliced) without having one thread affecting the 
processing capabilities of another thread. If any one (or more) 
processes would error, processing in the other threads would continue 
normally without the entire show coming to a grinding halt, 
regardless of what the mouse or some other input device's state was 
or was doing. This type of behavior is an important requirement in 
large complex systems. Without this feature large systems become very 
difficult to build and test reliably in any practical manner.

MCL contained a flag, ccl::*processing-events*. When T it indicated 
that a "normal" MCL thread was running (at this time process 
"Initial" would be in a "Suspended" state). When NIL, then process 
"Initial" was running. So it was possible for any Lisp code to check 
what thread was running and act accordingly, e.g.,

i) skip over mouse event processing and do actual work (e.g., drawing),

or,

ii) do mouse processing but leave other work (e.g., drawing) to 
another process that was calling the same code.

Would it make sense to set up such a similar flag that indicates when 
the initial thread is running? (thread "Initial" is the one that 
starts up when the app starts to run)

Since the Initial thread is so "control hungry" under the current OS, 
then it seems that it should avoid being in a error state at all 
costs. Could it not delegate event processing to another 
error-protected Lisp thread A, so that when A arrives in an error 
condition then Initial could initiate a stand-in error processor for 
failed thread A?