From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: otadmor Newsgroups: gmane.emacs.bugs Subject: bug#36362: New feature-x-check-server Date: Sat, 12 Feb 2022 11:54:29 +0100 Message-ID: References: <8736ju7dju.fsf@gmail.com> <8735ko4hwn.fsf@gnus.org> <87leygs90i.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000090036805d7d00293" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14897"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 36362@debbugs.gnu.org, Lars Ingebrigtsen , Noam Postavsky To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 12 11:55:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nIq3c-0003iR-Cs for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Feb 2022 11:55:12 +0100 Original-Received: from localhost ([::1]:50470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nIq3b-0000YJ-BR for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Feb 2022 05:55:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54846) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIq3S-0000Wv-OO for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 05:55:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nIq3R-0001ku-Mk for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 05:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nIq3R-0000VK-Im for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 05:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: otadmor Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Feb 2022 10:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36362 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 36362-submit@debbugs.gnu.org id=B36362.16446632881916 (code B ref 36362); Sat, 12 Feb 2022 10:55:01 +0000 Original-Received: (at 36362) by debbugs.gnu.org; 12 Feb 2022 10:54:48 +0000 Original-Received: from localhost ([127.0.0.1]:33585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIq3D-0000Uq-HC for submit@debbugs.gnu.org; Sat, 12 Feb 2022 05:54:47 -0500 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:33521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIq3B-0000Ud-U8 for 36362@debbugs.gnu.org; Sat, 12 Feb 2022 05:54:46 -0500 Original-Received: by mail-wm1-f43.google.com with SMTP id y6-20020a7bc186000000b0037bdc5a531eso3835850wmi.0 for <36362@debbugs.gnu.org>; Sat, 12 Feb 2022 02:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cRwFqGqvYjABKOoUr2rXO17rJcHru5X5DwR/ZD7O9+A=; b=fpiVH27iMiex3OWTIO/f+SrIn4UaSTERnbHDtnmDgBGy3U4xqbDL8qRF+PAzMzEhGj IaSerETlaq3RYYNZMdlCyXYMkarfTYyU0f/GEeqXuv05BpRcQu/lhC18ISHfX0+m782m MesJELXnmKjKuoQciC5YIJjwaCteLwPATSr0/H3uxelgqHkoBUFCbVuM5Ps/CkrGuw4l DX7nmWOQUb+n4ldQegyoZn1Go2Ws1pQM+YA1vwHFf5pLbwMkdCND/HBfI+mqNnuUCEOh QjZ+Vxlxkdxc6oBD6NQX3ib5VF/5p/tDBsFhVgZTKKukPx9kR36etZiSCWtfeqlqE7zb pv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cRwFqGqvYjABKOoUr2rXO17rJcHru5X5DwR/ZD7O9+A=; b=00HMGX/1VvkDn9zWe4JSWUQTnkbwUEkUYRzvf5dotsKXUtYY6K661cmviy53YmA3rF uSLgjrtHn+lRFHmcAAY7yIZMkx4DZmLT2nbNa3SQaa6Qh3ik8Yj7XNZFdYRyAIHMk2uM os15XApYG4slAVw9JwvvExdjFPTGNLJv6t+iDhVIyRn6UYk60Hl8DSqzewUzipx/hdUe 2PztWdVOhfGiAUCXvdw140xyPl437kxRiNz62FHzeGd+LyIDUgd9mxlVlXBObkdY6Kj9 AGpkbBMG0F04A4ayOaUJ7I/y1x960S2nRdx3cnakKoELpS2pt9o2dw9hqTbt8CDwP3iB Gs6w== X-Gm-Message-State: AOAM533zwSg+kaXntbbBmac5SkBJ2DFhf3k17EPfOdwnksAe/+alPiee WbW9nzb1/A29G24teirqMM4EZdV7CEw988r8hqY= X-Google-Smtp-Source: ABdhPJyb5GhShQc3PyhFZt4gSZdgQb3SyUgsgmokB846wARjVJTWzkAoce4dXMxF+ew4SbLSwdt4BjrV/Mp3HBpGAy0= X-Received: by 2002:a05:600c:1914:: with SMTP id j20mr3740381wmq.41.1644663279714; Sat, 12 Feb 2022 02:54:39 -0800 (PST) In-Reply-To: <87leygs90i.fsf@yahoo.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:226719 Archived-At: --00000000000090036805d7d00293 Content-Type: text/plain; charset="UTF-8" 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 wrote: > otadmor 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.) > --00000000000090036805d7d00293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As for your firat comment - this patch adds a lisp f= unction to check if the xserver is responsive. It does not run automaticall= y 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 e= xported function from the patch.
The patch was desig= n to not change existing behaviour of emacs. If you see somewhere this is n= ot the case I could fix that.=C2=A0
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.=C2=A0
Thirdly, this wha= t I saw when I debugged it.


On Sat, Feb 12, 2022, 10:56 Po Lu <luangruo@yahoo.com>= wrote:
otadmor <otadm= or@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<= br> > side effect ends the endless loop.=C2=A0 Some would say this patch is<= br> > fixing a bug of a dependency of emacs and not emacs itself (it is just=
> that emacs uses it in a certain way...).=C2=A0 This solution uses nati= ve
> 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.=C2=A0 Firstly, it is not portable and make= s
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.=C2=A0 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.=C2=A0 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.=C2=A0 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.)
--00000000000090036805d7d00293--