GNU bug report logs - #36362
New feature-x-check-server

Previous Next

Full log

Message #51 received at 36362 <at> debbugs.gnu.org (full text, mbox):

From: otadmor <otadmor <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 36362 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#36362: New feature-x-check-server
Date: Sat, 12 Feb 2022 11:54:29 +0100

[Message part 1 (text/plain, inline)]

As for your firat comment - this patch adds a lisp function to check if the
xserver is responsive. It does not run automatically for everyone, so only
those who are interested should call this function from their lisp
configuration. Personally I added run-at-time to call the exported function
from the patch.
The patch was design to not change existing behaviour of emacs. If you see
somewhere this is not the case I could fix that.
I can add ifdef to make this code compile only with this specific xlib.
Would that be ok in your opinion?
Secondly, the exported function gets the frame you wish to check.
Thirdly, this what I saw when I debugged it.


On Sat, Feb 12, 2022, 10:56 Po Lu <luangruo <at> yahoo.com> wrote:

> otadmor <otadmor <at> gmail.com> writes:
>
> > When running xlb function the code gets stuck in a native endless
> > loop. The patch I have added closes the fd of the xserver, which as a
> > side effect ends the endless loop.  Some would say this patch is
> > fixing a bug of a dependency of emacs and not emacs itself (it is just
> > that emacs uses it in a certain way...).  This solution uses native
> > timer (using signals) to detect the timeout. Upon reaching a timeout
> > it closes an the fd on the same thread as the xlb code (this is
> > because of how signals works).
>
> I am not happy with your change.  Firstly, it is not portable and makes
> very specific assumptions about the internals of Xlib, while we support
> any Xlib from X11R6 in the past to the foreseeable future, along with
> some alternative implementations.  We do not use any part of Xlib that
> forms part of the interface for protocol extensions, since Emacs is not
> an X11 protocol extension.
>
> Secondly, Emacs supports connecting multiple X displays at the same
> time.  Your code does not try to support that at all.
>
> Thirdly, I cannot understand what is returning EINTR: that error occurs
> only when the read from the X connection was interrupted by a signal.
>
> If the X server goes down (such as when your laptop goes to sleep), the
> connection eventually times out and closes, which then triggers an IO
> error that Emacs does handle correctly.  If it does not, then that is a
> bug in xcb and should be reported to their developers.
>
> I suggest to add an entry to etc/PROBLEMS describing your specific
> use case instead.
>
> > To do this is lisp we need to answer the following:
> > 1. How to find the fd of the current xserver using lisp?
>
> That is not possible, and I wouldn't agree to such a function.
>
> > 4. Is it even allowed to run lisp code while the main thread is in xlb
> > native code (stack frame is deep inside other library and this other
> > library was called from lisp).
>
> Yes, but not inside a signal handler (unless it is an IO signal, see
> block_input and friends.)
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.