[PATCH] Flush buffer in time for global (un)lock xserver operation

[Chen Gang]

> On Wed, 2019-12-04 at 18:24 +0800, chengang at emindsoft.com.cn wrote:
>> From: Chen Gang <chengang at emindsoft.com.cn>
>>
>> The global (un)lock xserver operations will have effect to the whole
>> system, and all the other gui apps have to be blocked, so the operations
>> should not be buffered, or may cause sync issue, e.g. reboot machine.
> 
> Enh. I can maybe see the point of this for XUngrabServer, but I think
> doing this for XGrabServer may actually make interactivity worse. With
> the code as it is currently, the GrabServer request will be buffered
> inside the client until something happens to flush it out (presumably
> something like QueryTree or GetImage that provokes a reply), and while
> it stays buffered other clients may still interact with the server.
> With this change you'll immediately write the request to the server,
> and you might lose your scheduler timeslice as a result, in which case
> not only will the grabbing client need to wait to reschedule but every
> other client will need to wait in line behind the grabbing client.
> 

Oh, for me, what you said is reasonable. I got the issue because the
XUngrabServer did not call _XFlush() immediately.

_XFlush for XGrabServer is not necesscary for my current issue, either
not good for the performance.

Originally, I felt XGrabServer and XUngrabServer were a pair, and I was
not quite sure enought. So I used _XFlush for both of them (it must be
safe enough, altough it has negative effect with the performance).

> Do you have a scenario in mind that this helps with? Does doing _XFlush
> only for XUngrabServer work just as well?
> 

At least for me, _XFlush only for XUngrabServer should be work well.

Welcome you to apply the patch with the new modification (only _XFlush
for UngrabServer).

By the way, I can not join in xorg-devel at lists.x.org mailing list. I
tried, but got "No ReCAPTCHA response provided". Welcome any ideas about it.

Thanks.