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

[Duncan Rose]

On Thursday, February 5, 2004, at 11:12 PM, Timothy Moore wrote:

>
> 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.

I'm hoping this will be fine, as long as CLIM redraws the sheets it 
resizes.

>> 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?

I don't think that will be necessary. Events appear to be working ok at 
the moment (although perhaps not very efficiently...)

>>
>> 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.

I was trying to minimise the length of time I had a view locked for. 
Again, I'm not sure this is necessary but it seemed like a good idea at 
the time (I think locking a view will block the window server until the 
lock is released; it's possible it just locks the thread responsible 
for the locked view (maybe even likely) but I haven't experimented with 
this yet).

I was thinking of maybe hunting out the drawing-intensive methods 
(which I think are in the pane realization code somewhere - I haven't 
looked yet) and creating :around methods which locked the focus, call 
next method, then unlocked focus. But again, I'm not far enough down 
the path to have tried any of this yet.

>>
>>> 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.

Pretty much all of it. I think the problem may well be to do with my 
(CLIM) events in that case. The back end isn't being asked to draw 
glyphs after key down / up events are processed. Time to put some debug 
into the McCLIM "core" code and see what's happening to them...

>> 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
>
>
> _______________________________________________
> mac-lisp-ide site list
> mac-lisp-ide at common-lisp.net
> http://common-lisp.net/mailman/listinfo/mac-lisp-ide
>