Reentrancy

[David Ayers]

Hello Richard,

you mentioned:
> All GNUstep applications are DO apps ... since DO is needed for
> pasteboard,
> services, opening documents on behalf of other apps, workspace
> notifications etc.
> So an app developer must assume that all their code needs to be safely
> re-entrant
> for instance.

OK, this is an assumption that is new to me and I had to slepp over but I
believe the bottom line is that it's a fact of life. Eventhough this seems
pretty hard to account for do given
- the viewManipulationDuringEventProcessing/display seperation of AppKit
- and probably the EODisplayGroup/EOAssociation/-willChange mechanism for
updating BO/Views of GDL2 (presumably since I don't know what this code
looks like, but I believe a performSelector:)

How could this be done? For example the NSUndoManager sends
theCurrentRunLoop
performSelector:@selector(_loop:) target:self ... in its setRunLoopModes:
method. My action method could set the run loop modes of theUndoManager
using
this method. I take it, the intention of sending performSelector:.. to
theRunLoop is to beginUndoGrouping once the current event processing is
finished. Otherwise the _loop: could have been called immediatly. But if my
action method would then call selectText: of an arbitrary anTextField, for
example, this would allow the _loop: to be called before the current event
is
finished! (This is acutally the same thing, that has happend with the
setViewsNeedDisplay:/_handleWindowNeedsDisplay: mechanism)

I'm not claiming to have "the answer" to this problem, but I want to know if
you also recognize this, or whether I'm missing something, and this isn't a
problem at all.

I believe when it get's down to it, OPENSTEP is lacking a mechanism to tell
theRunLoop to performSelector:target:argument:order:modes: which also take
an
indicator which insures that the method is performed once the runLoop is
idle.
(Or I missed this mechanism.) Then the caller of this method could decide
whether the method should be invoked "in a defined state" i.e. after any
event processing is finshed.

Would this solve my initial problem, i.e. should this be done in
setViewsNeedDisplay: when it sets up _handleWindiwNeedsDisplay:? I'm not
sure, in fact I'm almost inclined to say no. Well on second thought maybe it
would be OK because one could still force an immediate display be sending
displayIfNeeded directly. Hmm. haven't made up my mind, but can you follow
me?

Dave

PS: NSConnection: the static "class" variable timer isn't initialized to
nil;