[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GsTcpPort (NSDefaultRunLoopMode / _handleWindowNeedsDispaly:)
|
From: |
Richard Frith-Macdonald |
|
Subject: |
Re: GsTcpPort (NSDefaultRunLoopMode / _handleWindowNeedsDispaly:) |
|
Date: |
Fri, 5 Jul 2002 11:22:09 +0100 |
On Friday, July 5, 2002, at 10:58 AM, David Ayers wrote:
OK, my main Problem with the enable/disable apporach is the fact, that
it's not the views "fault" (or rather reponsibility). Any view or other
object interacting with the pasteboard server will have same problem,
and all would require this guarding of display.
It is NSPasteboard's attempt to allways get the "current" rootProxy of
the server. Normal DO messages to a proxy *DO* get sent in
NSConnectionReplayMode, and the don't provoke display.
I have just checked the source code ... normal messages are sent in
NSDefaultRunLoopMode
(see [GSTcpPort -sendMessage:beforeDate:]). The code waits for
*replies* in NSConnectionReplyMode
So to prevent your problem you would have to change the way messages are
sent as well as the way
connections are established. I'm not sure that doing this would cause
problems ... just worried.
Certainly, having the whole thing (connection, send, and receive) work
in NSConnectionReplyMode
sounds as though it might be the correct behavior - I'm just worried
about the possibility of
some sort of deadlock in DO applications because things are expecting to
get timers firing etc,
and they are being held up because the application is waiting for a DO
reply.
It's just during the reoccuring attempt to get the current rootProxy,
that GNUstep (unlike openstep) runs in NSDefaultRunLoopMode.
No it's not - but changing the send as well as the connection attempt is
no big deal to do.
Now maybe we could make it it's (NSPasteboard) responsibility to
notify that the runloop is about to run in NSDefaultRunLoopMode by
sending some method the App or posting some notification before and
after. Yet I belive it should be the responsibility of the object
accessing the rootProxy to "warn/unwarn" of the runloop being run in
NSDefaultRunLoop mode. Then NSApp or the windows could provide for
disable/enable display.
Euch.
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.
I can't verify any "other" event handling of OPENSTEP during the
accessing of the rootProxy except that the RunLoop is running in
NSConnectionReplayMode, i.e. the App is unresponsive at this time to
UI-Events.
In which case
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.
Well I'm not against differences in behavior, then maybe we should go
the "warn/unwarn" Notification route to allow core-frameworks and Apps
to provide for this "Unexpected" (In the case of OPENSTEP Apps) run in
NSDefaultRunLoopMode.
I rather think apps should be coded to expect run loops to be run in any
mode at any time.
However, I agree that doing unexpected things is not good.
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.
The actual messages to a procy *ARE* sent in NSConnectionReplayMode,
it's just the fact that NSPasteboard always "reestablishes" the
connection be getting the current rootProxy. (see -_pbs).
No. Check the source.
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.
Well it's only not reponding to events of NSDefualtRunLoopMode, which
is what OPENSTEP does. It will process events of NSConnectionReplyMode.
I'm not asking for an "immediate" change. Rather for further comments
and maybe we can get to the bottom of this.
I think you should change it and try it.
Just be aware that you need to change it for message sends as well as
connection attempts.
It is entirely plausible to me that using reply mode for connect/send)
is the 'right' thing to do,
and you have spotted a genuine bug here. I just want to be absolutely
sure that such a basic
change doesn't screw stuff up - so it should be tested very extensively.