[Xevie] Question about synchronous grabs

[Jim Gettys]

On Fri, 2004-11-12 at 17:14 -0800, Deron Johnson wrote:
> Thanks for the info, Jim.
> 
> I finally got around to looking at the types of grabs GNOME registers.
> Unfortunately for me, it registers lots of synchronous grabs. This means
> that I cannot simply ignore the synchronous grab cases while moving the
> event processing into the LG Display Server. I'm going to need to risk
> possible transcription errors and move the entire wad of event
> processing stuff into the Display Server.
> 

I don't think we can ignore passive grabs either.

I don't think that externalizing them will be a performance issue on
current machines, which are 100-1000x faster than in the past, so long
as the external applications don't get paged out.  The context switches
just don't take that long.

> BTW, you mentioned to me at one time that you had done some work in
> the X server event system before. How knowledgeable are you about
> the workings of the synchronous grab logic. If not, is there anybody
> still around who knows this stuff? It would be nice to have someone
> review my port for correctness.

I think it must have been Keithp who said this to you.  He's had his
fingers almost everywhere.

			Regards,
				- Jim


> 
> Jim Gettys wrote:
> > Yes, you are onto why there are passive grabs in X...
> > 
> > Here's an example scenario for passive grabs:
> > 
> > You want to click on a window to set the focus, pop the window to the
> > top, and also want the event to set the input point in the input window;
> > you want subsequent typing to go to the "right place".
> > 
> > So the window manager might set a passive grab on a window, get the
> > event, set the input focus and restack the windows, and then AllowEvents
> > and replay the event to set the input focus to the "right place", and
> > the user keyboard events will go to the "right place" in the right
> > order.
> > 
> > This allows X to do various operations reliably even if applications are
> > not immediately responsive, and avoid a ton of race conditions.
> > 
> > You can think of passive grabs as "traps" waiting to be sprung, so that
> > events can always get delivered in the right order, despite the need for
> > other processing.
> > 
> > Unfortunately, many of the current toolkits do not exploit this
> > capability in X as much as they might/should.  Machines are no longer
> > so slow, but if you are paged out, they can still take measurable
> > amounts of time before applications are able to respond....
> > 				- Jim
> > 
> > On Thu, 2004-11-11 at 11:58 -0800, Deron Johnson wrote:
> > 
> >>Does anybody know what is the purpose of a synchronous grab in X?
> >>Basically, a synchronous grab records incoming events while it is
> >>active instead of sending them down the event pipeline. Only when
> >>a client actively releases the synchronous grab does the event
> >>pipeline start flowing again. And the recorded events are first played
> >>back. So I know how synchronous grabs behave, but I'm not entirely
> >>sure that I know what purpose they serve.
> >>
> >>One purpose I can think of is to implement type-ahead (or mouse-ahead).
> >>The user clicks a button which brings up a dialog. The button click
> >>triggers a passive grab which is synchronous. The app then maps a
> >>dialog window. After the window is up the app releases the synchronous
> >>grab and any key events which the user has typed while the dialog
> >>window was coming up will be sent to the dialog window.
> >>
> >>Are there any other uses of synchronous grabs? How prevalent are
> >>apps that use synchronous grabs? Does anyone know whether GNOME or
> >>KDE use them?
> >>
> >>The reason I ask is because synchronous grabs account of a significant
> >>amount of complexity in the X server event code. I am questioning
> >>whether it is worth trying to support these in my Display Server event
> >>subsystem. The code is so complicated and involved that there are bound
> >>to be transcription errors during any port.
> >>
> >>
> >>
> >>_______________________________________________
> >>xevie mailing list
> >>xevie at freedesktop.org
> >>http://freedesktop.org/mailman/listinfo/xevie
> > 
> > 
>