[mcclim-devel] spec-compliant CLIM impossible on single-threaded systems?

[Clemens Fruhwirth]

Assume you have two stream panes in a single-thread CLIM implementation
(that is *multiprocessing-p* -> nil). By some means you trigger
stream-read-char on the first pane. As there is no character available
stream-read-char will block and start a subsequent event processing
loop, checking if there is a character arriving on its pane. But there
won't come any character. In the meanwhile the event processing loop
running inside of stream-read-char causes via some other handle-event
that a second stream-read-char is started. Again causing an event loop.

Problem #1: The event loop of the second stream-read-char does not
know anything about the loop condition of the first event loop.

Problem #2: Problem #1 can be curred by making some "global" state of
event conditions. However, It can't do anything about even if it would
know when the first stream-read is supposed to terminate. Because to
return to the first event loop, it would have to stop blocking, but it's
not allowed to do that. There is no way stream 1 can process its
character before stream 2 got its (and further assuming that the code
calling stream-read-char exits).

Conclusion: CLIM can not be implemented on a single-thread system as
it is specified. 

Continuations a solution? Rather not. event-read would to be specified
as a macro that takes a body argument used in a closure. For instance,

(event-read (event sheet)
  (process-event event))

But there is nothing like that in the CLIM spec. So we either support
stream reading cleanly or we forbid synchronous event processing at
all. We can't have both. Not with this CLIM spec. 

(Remark: UCW got it right. A former version of UCW uses continuations
to fix the problem of "proper problem encoding". Our brain does not
think in terms of events. We don't envision problem solutions in terms
of state machines. We envison solutions as linear flow. See:
http://common-lisp.net/project/ucw/docs/html/rest/rest.html - An
interesting thing about UCW is also that it doesn't require deep
nesting of sexps as it uses (actually has used) a code walker to
transform code into CPS. It can be found here 
http://common-lisp.net/project/bese/docs/arnesi/html/Automatically_Converting_a_Subset_of_Common_Lisp_to_CPS.html
)

I actually wanted to write about the fact that McCLIM does not have
per-pane event queues. But before I can have a look at this topic, I
rather discuss how CLIM events should be handled at all. If we are
actually going to change something in this area, I would also like to
define:

Who is allowed to read an event and when?
What are the priorities if there are more than one event consumers?
How is event consumption of event-read related to handle-event; Is
handle-event the default event-processing mechanism by the default
event-reader, so that handle-event is a fallback if there are no other
event-readers (than the default)?

See stream-read-char, stream-read-char-no-hang, handle-non-stream-event
in stream-input.lisp, standalone-event-loop in panes.lisp,
simple-event-loop in frames.lisp for more.
-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap at endorphin.org