unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: otadmor <otadmor@gmail.com>
To: Po Lu <luangruo@yahoo.com>
Cc: 36362@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
	Noam Postavsky <npostavs@gmail.com>
Subject: bug#36362: New feature-x-check-server
Date: Sat, 12 Feb 2022 11:54:29 +0100	[thread overview]
Message-ID: <CAJd1wGKQKoXQHpPwDuYNQQhcD_Bb4XfYgK84D3xT0fYGumpXHA@mail.gmail.com> (raw)
In-Reply-To: <87leygs90i.fsf@yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

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@yahoo.com> wrote:

> otadmor <otadmor@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.)
>

[-- Attachment #2: Type: text/html, Size: 3535 bytes --]

  reply	other threads:[~2022-02-12 10:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24 17:05 bug#36362: New feature-x-check-server otadmor .
2019-06-27  9:57 ` bug#36362: Patch for the current 26.2 version otadmor .
2019-06-27 15:10 ` bug#36362: New feature-x-check-server Noam Postavsky
2019-06-28  0:34 ` Noam Postavsky
2022-02-12  8:18   ` Lars Ingebrigtsen
2022-02-12  9:13     ` otadmor
2022-02-12  9:56       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-12 10:54         ` otadmor [this message]
2022-02-12 11:17           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2019-06-30 20:41 ` bug#36362: The elisp timer otadmor .
2019-07-30 19:54 ` bug#36362: Tag this report as bug otadmor .
2019-07-31  2:27   ` Eli Zaretskii
2019-07-31  7:01     ` otadmor .
2019-07-31 11:50       ` Noam Postavsky
2019-07-31 17:00         ` otadmor .
2019-07-31 17:18           ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJd1wGKQKoXQHpPwDuYNQQhcD_Bb4XfYgK84D3xT0fYGumpXHA@mail.gmail.com \
    --to=otadmor@gmail.com \
    --cc=36362@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=luangruo@yahoo.com \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).