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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36362 in the body.
You can then email your comments to 36362 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "otadmor ." <otadmor <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: New feature-x-check-server
Date: Mon, 24 Jun 2019 20:05:39 +0300

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

A new native method to check connectivity of xserver.

-- 
Gretz,
Ofir Tadmor

ICQ: 77685691
Mail: otadmor <at> gmail.com

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

[0001-Add-x-check-frame-lisp-method-to-check-frame-x-serve.patch (application/octet-stream, attachment)]

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

From: "otadmor ." <otadmor <at> gmail.com>
To: 36362 <at> debbugs.gnu.org
Subject: Patch for the current 26.2 version
Date: Thu, 27 Jun 2019 12:57:25 +0300

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

Patch for version 26.2 can be found here:
https://raw.githubusercontent.com/otadmor/emacs-conf/master/xterm.c.patch
Patch for the current master branch in git on the original message.

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

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: "otadmor ." <otadmor <at> gmail.com>
Cc: 36362 <at> debbugs.gnu.org
Subject: Re: bug#36362: New feature-x-check-server
Date: Thu, 27 Jun 2019 11:10:22 -0400

"otadmor ." <otadmor <at> gmail.com> writes:

> A new native method to check connectivity of xserver.

Can you explain a bit when/why this is useful?  As it stands this patch
is rather "apropos of nothing"...

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: 36362 <at> debbugs.gnu.org
Cc: "otadmor ." <otadmor <at> gmail.com>
Subject: Re: bug#36362: New feature-x-check-server
Date: Thu, 27 Jun 2019 20:34:45 -0400

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

[forwarding to list, please use "Reply All" to keep 36362 <at> debbugs.gnu.org on Cc]

[Message part 2 (message/rfc822, inline)]

From: "otadmor ." <otadmor <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#36362: New feature-x-check-server
Date: Thu, 27 Jun 2019 22:12:56 +0300

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

I have some non consistency of the terms client and server. Some refer to
the emacs client/daemon, some refer to the xserver, emacs as x11 client.

Hi,
I have this scenerio:
1. Laptop with Windows 10 host and Ubuntu 1804 vm.putty and xming (latest
versions) are installed on host and emacs 26.2 on the vm.
2. Connect with putty via sshx to the vm and run emacsclient -c. Doest
really matter how emacs deamon is started (with the ex, via the ssh as
emacs -daemon, directly in the vm, as sysctl -user start emacs).
3. Close the laptop lid so it goes to sleep.
4. Open the lid and reconnect with sshx and emacs client -c.
5. The second emacs client causes emacs daemon to stuck on xcb select (they
have no timeout). The emacs client is still running correctly before the
second emacs client.

The propose is to have this connectivity check native function + timer
which executes it on all existing frames every few seconds.

This native function closes the fd of the xcb and causes the select to
return EINTR. xcb have internal infinate loop Incase of EINTR, so closing
the fd is necessary to get out of this infinite loop. Closing the fd also
causes libx11 to realize the connection was closed and call the error
handler of emacs for x11 failures for a clean termination of the resources
in emacs.

This native function is consist of a a native timer with a signal handler
to handle when this timer expires. I have set the native timer for 0.5
seconds and it is configurable using an elisp variable. When the server was
not disconnected this timer don't expires, doesnt close the fd and returned
immediately without waiting 0.5 seconds. When the client crashed because of
sleep, the native code will have to wait before realizing it. I have
selected GetGeomerty arbitrarly. This is usually used by emacs and I don't
believe it has an extra side effect. The xcb knows the sequence numbers of
the requests and should not be confused with other GetGeomerty/other
non-GetGeomerty requests.

Shalom.

On Thu, Jun 27, 2019, 18:10 Noam Postavsky <npostavs <at> gmail.com> wrote:

> "otadmor ." <otadmor <at> gmail.com> writes:
>
> > A new native method to check connectivity of xserver.
>
> Can you explain a bit when/why this is useful?  As it stands this patch
> is rather "apropos of nothing"...
>
>

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

From: "otadmor ." <otadmor <at> gmail.com>
To: 36362 <at> debbugs.gnu.org
Subject: The elisp timer
Date: Sun, 30 Jun 2019 23:41:45 +0300

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

This is the code of the elisp timer. This is actually a bug fix.

(defun check-frames-connection-timer ()
(safe-check-frames-connection)
(run-at-time 2 nil 'check-frames-connection-timer))
(run-at-time 2 nil 'check-frames-connection-timer)
(defun safe-x-check-frame (frame)
(condition-case nil
(x-check-frame frame)
(error nil)))
(defun safe-check-frames-connection ()
(when (functionp 'x-check-frame)
(dolist (frame (frame-list))
(when (eq (framep frame) 'x)
(safe-x-check-frame frame)))))

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

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

From: "otadmor ." <otadmor <at> gmail.com>
To: 36362 <at> debbugs.gnu.org
Subject: Tag this report as bug
Date: Tue, 30 Jul 2019 22:54:29 +0300

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

Hey,
How can this be escalated to be a bug and be placed in the bug list?

Thanks.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "otadmor ." <otadmor <at> gmail.com>
Cc: 36362 <at> debbugs.gnu.org
Subject: Re: bug#36362: Tag this report as bug
Date: Wed, 31 Jul 2019 05:27:22 +0300

> From: "otadmor ." <otadmor <at> gmail.com>
> Date: Tue, 30 Jul 2019 22:54:29 +0300
> 
> How can this be escalated to be a bug

A request for a new feature cannot be a bug.

> and be placed in the bug list?

It's already there.

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

From: "otadmor ." <otadmor <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36362 <at> debbugs.gnu.org
Subject: Re: bug#36362: Tag this report as bug
Date: Wed, 31 Jul 2019 10:01:41 +0300

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

This so called feature fixes the DOS bug I have described on previous
messages. It can be easily reproduced by the steps I wrote there.

On Wed, Jul 31, 2019, 05:27 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: "otadmor ." <otadmor <at> gmail.com>
> > Date: Tue, 30 Jul 2019 22:54:29 +0300
> >
> > How can this be escalated to be a bug
>
> A request for a new feature cannot be a bug.
>
> > and be placed in the bug list?
>
> It's already there.
>

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

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: "otadmor ." <otadmor <at> gmail.com>
Cc: 36362 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#36362: Tag this report as bug
Date: Wed, 31 Jul 2019 07:50:39 -0400

"otadmor ." <otadmor <at> gmail.com> writes:

> This so called feature fixes the DOS bug I have described on previous
> messages. It can be easily reproduced by the steps I wrote there.

The line between bug and feature request can sometimes be fuzzy (in this
case, you framed the solution as a new feature so it looks like a
feature request).  But there's no such thing as "escalation" here
anyway, we don't have extra people waiting to be assigned to solving
non-wishlist bugs.

You might want to ask on emacs-devel, maybe someone there will
understand the problem better and have some useful feedback about it.

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

From: "otadmor ." <otadmor <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 36362 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#36362: Tag this report as bug
Date: Wed, 31 Jul 2019 20:00:54 +0300

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

How can I forward this to emacs devel?

On Wed, Jul 31, 2019, 14:50 Noam Postavsky <npostavs <at> gmail.com> wrote:

> "otadmor ." <otadmor <at> gmail.com> writes:
>
> > This so called feature fixes the DOS bug I have described on previous
> > messages. It can be easily reproduced by the steps I wrote there.
>
> The line between bug and feature request can sometimes be fuzzy (in this
> case, you framed the solution as a new feature so it looks like a
> feature request).  But there's no such thing as "escalation" here
> anyway, we don't have extra people waiting to be assigned to solving
> non-wishlist bugs.
>
> You might want to ask on emacs-devel, maybe someone there will
> understand the problem better and have some useful feedback about it.
>

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

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: "otadmor ." <otadmor <at> gmail.com>
Cc: 36362 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#36362: Tag this report as bug
Date: Wed, 31 Jul 2019 13:18:34 -0400

On Wed, 31 Jul 2019 at 13:01, otadmor . <otadmor <at> gmail.com> wrote:
>
> How can I forward this to emacs devel?

Just send a new message to emacs-devel <at> gnu.org.

You can put a link to https://debbugs.gnu.org/36362 in the message so
people can read it for more background info.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 36362 <at> debbugs.gnu.org, "otadmor ." <otadmor <at> gmail.com>
Subject: Re: bug#36362: New feature-x-check-server
Date: Sat, 12 Feb 2022 09:18:32 +0100

> This native function closes the fd of the xcb and causes the select to
> return EINTR. xcb have internal infinate loop Incase of EINTR, so closing
> the fd is necessary to get out of this infinite loop. Closing the fd also
> causes libx11 to realize the connection was closed and call the error
> handler of emacs for x11 failures for a clean termination of the resources
> in emacs.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I don't think it would be appropriate to add a function like this to the
C level of Emacs, because the use case is very limited.  And I think you
can basically get the same functionality by using the xelb package
(which talks to the X servers from Lisp).

So I'm closing this bug report as a "wontfix".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

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

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).
To do this is lisp we need to answer the following:
1. How to find the fd of the current xserver using lisp?
2. How to call syscall close using lisp?
3. How to create native timers using lisp?
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).

On Sat, Feb 12, 2022, 09:18 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> > This native function closes the fd of the xcb and causes the select to
> > return EINTR. xcb have internal infinate loop Incase of EINTR, so closing
> > the fd is necessary to get out of this infinite loop. Closing the fd also
> > causes libx11 to realize the connection was closed and call the error
> > handler of emacs for x11 failures for a clean termination of the
> resources
> > in emacs.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I don't think it would be appropriate to add a function like this to the
> C level of Emacs, because the use case is very limited.  And I think you
> can basically get the same functionality by using the xelb package
> (which talks to the X servers from Lisp).
>
> So I'm closing this bug report as a "wontfix".
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

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

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

From: Po Lu <luangruo <at> yahoo.com>
To: otadmor <otadmor <at> gmail.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 17:56:45 +0800

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 #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)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: otadmor <otadmor <at> gmail.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 19:17:29 +0800

otadmor <otadmor <at> gmail.com> writes:

> 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.

No, it's only to solve a niche problem and will lead to constant
maintenance hassle with updates to Xlib.

> 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?

No, see above.

> Thirdly, this what I saw when I debugged it.

Then the solution is to report the bug to the developers of whatever
component is causing the bug, and then to ack so we can describe it in
PROBLEMS with whatever workaround they might recommend.  Of course, you
are free to keep using your change yourself.

Thanks in advance.

Previous Next

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