NSRunLoops (Distributed Objects and Modal Windows)

[David Ayers]

Hello all,

I've been pondering about NSRunLoops and flow control in OpenStep* Apps, and
I became aware of some fundamental aspects that I hadn't fully realized
before, yet I believe an OpenStep developer should be aware of. The Docs
from Apple
(http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/Programmi
ngTopics/InputControl/index.html) haven't addressed this topic as in depth
as I believe necessary. I might be alone with this view, but I though I
might offer it to you all and maybe inspire some better documentation in the
GNUstep version of the Docs.

First of all, NSRunLoop is not something I fully understand (actually I
believe I'm still far from understanding major concepts but there are a few,
which I believe to have a better grasp of now.)

RunLoops poll input sources to dispatch control. This means that the RunLoop
waits for a click of a mouse key, pressing of a keyboard key, firing of a
timer, recieve a message from another process and the like. It also has
mechanism for delayed execution. This delayed execution is used for display
for example. This allows your app-code to respond to an event by changing
the state of all relevant objects (seting all views that need display for
example), and after the event has been fully processed, th delayed "event"
is triggered to do the actual display.

All of the above is actually described by Apple very well, but what I think
needs some more elaberation is the following:

1. When an alert panel is displayed, or any other modal window, a the
currentRunLoop is rerun. Because now the only UI events which are located in
this window processed, we have a more or less "defined" situation. Note that
timers and DO messages are still recieved regardless of beeing in the modal
window.

2. When a message is sent via DO (i.e. NSPort's sendBeforeDate:... or in the
case of GNUstep's GSTcpHandle -sendMessage:beforeDate:) the currentRunLoop
is rerun. This can happen, while the outer "run" is already processing
another event! (This is currently the case when selectText: is called.)

3. (are there any other standard actions that rerun the currentRunLoop or
even start a new one? Please insert here.)

If you are writing a DO server, you should take care to make your methods
reentrant, if you plan to call back, send other DO messages during the
processing of messages or have a UI with a modal window. If the original
method changes the state of an object (or the process in general), it should
take care to always be in a defined state before sending another DO message
or opening a modal panel. (Defined state meaning being able to accept new
messages unrelated to the current event processing.)

Imagine an App that launches a tool which does intense data processing in
the background. The user clicks a button to launch the tool. The action
method launches the tool and the user is informed of the successful launch
through a modal panel "Tool successfully startet: <OK>"(he is still in the
action method). Since he is interested in the results he waits. The tool
finishes and informs the app via DO. The app recieved this method in the
rerun RunLoop of the panel. Upon executing this event, the app informs the
user with a new modal panel "Tool successfully finished: <OK>". The user
must now work his way back through the stack. First he must acknowledge the
finishing, then the starting and now we're back in the original action
method, which exits and now we're back in the original RunLoop (run). If the
user acknowlegded the first Panel before the tool was finished, then the
main loop would have recieved the finished message. This is a trivial
example just to show, that the app can recieve these messages while it is in
different states. Since the state of the app wasn't important for the
messages this doesn't cause any problems in this example, yet one should be
aware of it.

In my current post about NSTextField's become firstResponder, there is
something that the user starts to notice about this behavior. Since
selectText: calls copySelection which sends a remote message, the RunLoop is
rerun during copySelection and therefor the window is redisplayed
immdediatly. In this case causing a curiosity when (my verions of)
NSTextField gets clicked on, by shortly showing the entire content selected
during becomeFirstResponder, before the mouseDown: corrects the selection,
before user input is accepted again from the main RunLoop

But I do believe, that for an app that, works intensly with DO and call
backs, this could become a serious problem. I would plea for a very
restrictve use of DO and modal panels, eventhough I believe this could be
something next to impossible given:
- the frontend/backend design (which I haven't actually taken a look at yet,
so I'm not actually sure it is relevant.)
- the Distributed Notifcation Center
- the Pastebord Server

Could someone direct me to some more documentation dealing with this matter?
I'm looking for a more or less fail-safe approach in designing a DO Server,
and it would be nice, if it could have a UI.

Thanx 4 anybody who took the time to bear with me through this mail ;-)

Dave

*OpenStep as in Spec
*OPENSTEP 4.2 as in Apple's implementation