[mac-lisp-ide] runloops, threads, etc.

[Timothy Moore]

On Feb 5, 2004, at 11:39 PM, Duncan Rose wrote:
> Basically what I do is subclass NSView with Lisp objects using 
> def-objc-class and override the event methods. Each of these event 
> methods looks like:
>
> (ccl::define-objc-method ((:void :mouse-up event) lisp-view)
>   (add-event-to-queue self event))
>
> The add-event-to-queue method converts the Cocoa event into a CLIM 
> event and appends it to a list; the McCLIM event processing pops 
> events off the list when it wants them and does its stuff. This 
> provides a mechanism allowing Cocoa to force events on the back end 
> code, and for CLIM to request them as needed.
>
That's all fine. What I've been worried about all along is "events" 
going the other way. For example, the layout of the CLIM applications 
changes, so NSViews need to be deleted (perhaps) and resized.
> It might be easier to implement this in send-event rather than 
> implementing each event method individually, but I'm only at 
> pre-pre-alpha stage currently.
>
> There is definitely mention in the Apple docs that all threads have a 
> run-loop created for them, and that any thread that *starts* the 
> run-loop can process events. So I don't think all is lost for handling 
> events safely in a multi-threaded application. It may be the case that 
> multiple run-loops can only be run if no inputs are shared; I didn't 
> get far enough in my experimentation to say either way.
Do you want/need to use a Cocoa specific mechanism for passing messages 
between threads instead of the CLIM event queues?
>
> That said, I still get the occasional Cocoa error, "Unable to unlock 
> topmost reader" but that may be the way the back end is structured at 
> the moment. Because CLIM keeps track of what's been drawn and what 
> needs redrawing, I don't make use of the draw-rect method at all - so 
> every drawing operation currently does a lock-focus and a focus 
> release. This means (for drawing something like a scroll-pane) there 
> are dozens of lock - draw - unlock operations in a very short period 
> of time, which I suspect may cause the problems (it seems to happen 
> mostly when there's lots of debug being output on a separate window). 
> Hopefully this won't be (such) a problem when native panes are 
> implemented (and I suspect there are ways around the problem anyway if 
> necessary - but it's not a priority at the moment).
You might think about keeping a pane's medium (view) locked from the 
first drawing operation up to the call to force-output in the code that 
waits for events.
>
>> He and I have been discussing a merge; if debugging event-handling is 
>> holding him up, and it turns out to be the same sort of problem you 
>> described, then it's possible that in the forthcoming merge he and I 
>> can fix things by switching to the Cocoa-event-loop-centric model.
>>
>
> I'm actually getting very close to feeling ready to do a "release" 
> (i.e. let somebody else see the code 8-). I'm waiting on implementing 
> mouse moved events (hopefully will be done tonight), and getting 
> user-input displayed in the window (key-up / key-down events are 
> already received but seem to have no effect). The user-input display 
> "problem" for me at the moment is I'm not clear on whether CLIM 
> responds to a key event by drawing a glyph, or if I should draw the 
> glyph on my own and then just report the key event to CLIM - so it may 
> be quite straight-forward to resolve. I'll be looking at that 
> tomorrow.

I'm not sure how much of CLIM you're using at this point, but CLIM does 
expect to draw the glyphs itself after a key event on a stream.
> Interestingly (or maybe not) CLIM and Cocoa provide very similar 
> facilities for much of their windowing functionality. Unfortunately 
> its done differently enough to be a bit of a pain.
>
Sigh, yeah...
Tim