Re: GsTcpPort (NSDefaultRunLoopMode / _handleWindowNeedsDispaly:)

[Richard Frith-Macdonald]

On Friday, July 5, 2002, at 09:09 AM, David Ayers wrote:

> Finally (I think I got it)! I was on the wrong (or rather a different) 
> track the whole time. But this should solve the flashing. Carefull, I 
> haven't had the opertunity to test it, and won't until Saturday. But if 
> I'm wrong, some one (Richard ?) might be able to tell my why before 
> hand.

In GNUstep, the libraries are carefully designed never to use threads -
partly for portability (when this was first being written, a lot of 
systems
did not have reliable threading), and partly so that, unless the 
application
programmer specifically wants/needs them, you won't have threading and 
won't
suffer the performance degradation caused by the locking they make 
necessary.

I think that MacOS-X sends DO messages in separate threads - so that the
application is able to handle incoming messages while waiting for the 
send
to complete.  In GNUstep, the messages are sent in NSDefaultRunLoopMode 
to
achieve the same sort of effect ... and establishing the connection is
treated as part of the message send operation.

This might lead to a slight difference in behavior as in GNUstep both 
establishing
a new connection, and sending a message to the connection will result in 
an
iteration of the run loop in the default mode, while in MacOS-X they may 
not.

So ... if you want to prevent this, you would have to change the code 
for sending
messages (like a message to the pasteboard server) to run in reply mode, 
not just
the code for establishing the connection.
I'm not sure what the ramifications of this might be ... basically, the 
code is
designed to *permit* the app to respond to events while making a DO 
call, and
what you are aiming to do is to *prevent* the app from responding to 
events.
As such, I think this may be very much the wrong approach to take, and 
the idea
of temporarily disabling display in a single view or window seems much 
safer.
My fears may be wrong ... but I think we'd need to be *extremely* 
careful about
altering such basic behavior.