Re: about RunLoop, joystick support and so on

[Xavier Glattard]

Richard Frith-Macdonald <richard <at> tiptree.demon.co.uk> writes:
> (...)
> >> That's perhaps a bug ... as I understand it the code it supposed to
> >> return an X or windows event if it has already been received, and if
> >> no event has been received, call the runloop to wait for more
> >> events.  As long as that is working it's fine, but if the attempt to
> >> check for an event already received also does a read to get new
> >> events, then there is indeed the problem you describe of the runloop
> >> never being called.  If this is happening, it's not a bug in the
> >> runloop, just a subtle bug in the backend (in that it is failing to
> >> run the runloop when it should).  Such a bug ought to be fairly easy
> >> to fix ... a crude fix would be to run the runloop once  before
> >> fetching each item from the windows message queue or X event queue.
> >
> > No : the problem would then be moved to the runLoop : if many non gui
> > events occur in the runLoop, gui events would never be handled.
> 
> I don't follow that argument ... the gui events and non-gui events  
> would be intermingled, so gui events would be handled.

Ok, i now understand. You're right : that's crude :-)

> >> A more efficient option might be to use different calls to examine
> >> the windows/X event queues (ones that don't read in new events), or
> >> to count the events available each time the runloop signals event
> >> availability, and re-run therunloop after the count of events has
> >> been processed.
> >
> > IMHO the best option would be to manage all events (gui and non gui)
> > in one place, saying the runLoop. One loop could be :
> >
> >  - for each source of events : get one event if available (not wait)
> >  - if there is no event, wait (until a timer fires)
> >  - sort the events in a queue
> >  - return the oldest event
> >
> > This mechanism would need an other queue in the runLoop (or one more
> > queue for each mode ?). May be they already exist (?)
> 
> The runloop works like this ...
> 
> 1. fire timers and find the ext timer in the future
> 2. call select()/poll() to wait for the set of all events we are  
> interested blocking until there is an event or it's time for the next  
> timer to fire
> 3. when that system call returns, call the callback methods for all  
> the objects interested in any of the events found
> 4. optionally, go back to (1)
> 
> So no queue is required by the runloop, it always dispatches all the  
> available events when it is run.  It can also be told to run through  
> once without blocking ... that has the effect of firing all the  
> timers and dispatching any events which are immediately available.

A queue is needed _if_ the events have to be sorted, in a runLoop that
handles _all_ events (gui and other).

An other method would be to keep somewhere an index to the last source
that fired an event, and it would be the last to be check the next time the
runLoop is run. Looks better :-)

If the runLoop would handle all events :
1. [NSApp -run] would not use [-nextEventMatching:]
   but simply send [runLoop -runUntilDate:]
2. [GSDisplayServer -getEventMatchingMask:...] would not run the runLoop
3. The runLoop would check the displayServer like any other sources and
   then any incoming event would be send to NSApp

I do think that all events have to be handled at the same level,
the RunLoop. That's what the spec say. And afaik they don't say that
[NSApplication -nextEventMatching:] is supposed to run the loop.

Xavier