Re: [PATCH] Flush buffer in time for global (un)lock xserver operation
On 2019/12/12 下午7:01, walter harms wrote: > > short version, > can you provide an example works.c vs. not_works.c ? > > re, > wh > Excuse me, I did not write any example .c files. Originally, I directly fixed the gui quiting issue by adding _XFlush() after GetEmptyReq() for XUngrabServer in libX11. The issue details are: - Caja unlocks the xorg, but does not send the unlock event in its que. - Caja then prepares quiting, and wait event for XSession. - Now, XSesssion is waiting xorg for some gui related communication. - But Xorg is locked by Caja, and can't get any messages from XSession. - So the whole gui is dead. For analyzing: - We can gdb xorg, p *(clients[GrabInProgress]->clientIds), we know it is locked by caja (clients and GrabInProgress are all global objects, so we can get the value in release version with individual debug symbols). - We can gdb xsession (in my case, it is emind-session which is based on mate-session), and print its stack to know it is waiting for xorg. gdb caja and print its stack to know that it is waiting for xsession. - Modify libX11 to save the display object pointer, and gdb caja again. Print the display object's buffer and bufptr, then check the contents between buffer and bufptr to know the unlock event is in its buffer. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Flush buffer in time for global (un)lock xserver operation
Am 12.12.2019 03:13, schrieb Chen Gang: >> On Wed, 2019-12-04 at 18:24 +0800, cheng...@emindsoft.com.cn wrote: >>> From: Chen Gang >>> >>> 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). > short version, can you provide an example works.c vs. not_works.c ? re, wh > By the way, I can not join in xorg-devel@lists.x.org mailing list. I > tried, but got "No ReCAPTCHA response provided". Welcome any ideas about it. > > Thanks. > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Flush buffer in time for global (un)lock xserver operation
> On Wed, 2019-12-04 at 18:24 +0800, cheng...@emindsoft.com.cn wrote: >> From: Chen Gang >> >> 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@lists.x.org mailing list. I tried, but got "No ReCAPTCHA response provided". Welcome any ideas about it. Thanks. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Flush buffer in time for global (un)lock xserver operation
On Wed, 2019-12-04 at 18:24 +0800, cheng...@emindsoft.com.cn wrote: > From: Chen Gang > > 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. Do you have a scenario in mind that this helps with? Does doing _XFlush only for XUngrabServer work just as well? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
