Re: thread safe setNeedsDisplay:

[Richard Frith-Macdonald]

On Tuesday, October 29, 2002, at 11:36  pm, Pierre-Yves Rivaille wrote:

> I've implemented a "thread safe" setNeedsDisplay: (and 
> setNeedsDisplayInRect:).
> It behaves as it is supposed to according to the Cocoa doc :
> when called from a working thread (i.e. not the first one), the 
> setNeedsDisplay: method behaves as if it had been called from the main 
> thread.
>
> This is done by passing a message from the worker thread to the main 
> thread telling it to call setNeedsDisplay:. However the message is not 
> passed using NSConnection objects as the message needs to be 
> transfered whatever the current runloop mode is (ConnectionReply, 
> DefaultRunLoop, ModalPanelRunLoop or EventTrackingRunLoop).
> To do so, I've added a GSAppKitInterThreadRunLoopWatcher to the main 
> thread. It does wait on a socket. Whenever a worker thread calls 
> setNeedsDisplay:, the method's arguments are added to an array and one 
> byte is written on the socket. Then the 
> GSAppKitInterThreadRunLoopWatcher reads the method's arguments and 
> call setNeedsDisplay: in the main thread.
>
> The code is not ready for integration is CVS as it is not polished. 
> However I'd like to have some advice on my use of 
> NSRunLoop/GSRunLoopWatcher and on the way the method's call is sent to 
> the main thread.
>
> Here are the 3 patches
> <NSApplication.m.patch><NSRunLoop.m.patch><NSView.m.patch>
> and a sample program <ThreadTest.tgz>
>
> I hope my explanations were clear enough...

I have to go out now, and don't have time to go through your stuff in 
detail but ...

Your email prompted me to commit the implementations of the new 
foundation methods for
performing a selector in the main thread (introduced in macos 10.2)
The reason I hadn't committed is that I haven't actually 
tested/debugged them yet, however
since nothing currently uses them I think it was harmless to commit 
them.

My guess is that Apple added these to the foundation mainly to support 
threaded operation
of the appkit ... so you could probably use them for this 
setNeedsDisplay code ... please give
them a look - it would let use do things in a 'standard' way.

As far as I can tell, your code looks straightforward and workable, but 
using the foundation
method might be preferable.  I think the main difference is that the 
foundation method would
cause the underlying 'perform' to be done when the main run loop 
cycles,  and your code
would force the loop to run nearly immediately?
Perhaps the runloop modes to use for the perform operation should 
include
NSConnectionrReplyMode (you mention that in the email, but I didn't see 
it in the patch)
though I'm not sure about whether that's desirable.