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 10:13:28 +0100 Message-ID: References: <8736ju7dju.fsf@gmail.com> <8735ko4hwn.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000059222405d7ce99cf" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3800"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 36362@debbugs.gnu.org, Noam Postavsky To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 12 10:17:43 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 1nIoXH-0000nc-JK for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Feb 2022 10:17:43 +0100 Original-Received: from localhost ([::1]:60236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nIoXG-0006MX-Bi for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Feb 2022 04:17:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nIoTi-0005KB-V2 for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 04:14:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39575) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nIoTi-0001zO-Ji for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 04:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nIoTi-0006Eo-EA for bug-gnu-emacs@gnu.org; Sat, 12 Feb 2022 04:14:02 -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 09:14:02 +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.164465722723950 (code B ref 36362); Sat, 12 Feb 2022 09:14:02 +0000 Original-Received: (at 36362) by debbugs.gnu.org; 12 Feb 2022 09:13:47 +0000 Original-Received: from localhost ([127.0.0.1]:33472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIoTT-0006EE-B7 for submit@debbugs.gnu.org; Sat, 12 Feb 2022 04:13:47 -0500 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:44843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nIoTR-0006Dw-O7 for 36362@debbugs.gnu.org; Sat, 12 Feb 2022 04:13:46 -0500 Original-Received: by mail-wr1-f49.google.com with SMTP id u1so5100133wrg.11 for <36362@debbugs.gnu.org>; Sat, 12 Feb 2022 01:13: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=g1k56ym1fThxqS51p/TyyH2rCTlkJZdambV7BsWb+YU=; b=JGTwjZZ5MSKhbEPomaag2y+mgAX/xdf/slxq73TwCn9Qx3E+cTJst0TelM7bBejJ8Y Kfu90rEkKdYU7BOuHvCJVA+wRlA5aEkRWV8V3c0ps0kcAMbCbMlo53v7TVGm8iwnxlbt 8DfMVJhsZEkgqsMCFMkj/YK6tHBuh30f2mbXTsPa9pY932iE5enZvT8pE5YjdYzzUchA 3YCqIkVARsX0qWRrwh0g/RwLLc3I1to3fRW78JPALun0CXfvbW7ENIt1FX6ygTaC+ZmF uE5Txlax+3NkWj+WNb+sk5ImDSQMs8Xni8FpucW4e0Cr0FAxbqCQGd72gT8hXG4wqz36 b3Cw== 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=g1k56ym1fThxqS51p/TyyH2rCTlkJZdambV7BsWb+YU=; b=avmBBB2v8cY/cYc0YppUyXXHIXjqLlvws9CM3vjjprSM3IWC7nzirdojkl0R4aUUWh 34IXIOiV2zYpkMWXoyg/OwfvAaSYMdVSNM9z7k12v9JI7AMKm7y7/yvY0Tj6jhrvW/5L JJhHqpu8ZpHoAxcddXLnfAcdIZPvlc3hfZ2h2BZKBgNXuye/EUxQzteBB+MmEbXhdAfT GQEiazqP2g5ypWl2D1Nz1ojnF2/OOQqGSwszCPEj30/3crvXYtAm2B8xCq9tFo3SagRF cmH5nfJgazaOAVfZbfF0Nfo+YaC3W5rTOWm7zmo5aqesk2gLoGMPcdlYHGEWctZcsNgN 4jZQ== X-Gm-Message-State: AOAM533bPQgebipOXlslkbCQ2mSO7LYX2EksPBryaqONQ6uhoAW8mOtF HmYoH1/e+AXOuXDaJyuYuiWFtY8ppiu5ir4pBOI= X-Google-Smtp-Source: ABdhPJzSrOR6D0rgUqAMZpLLTtddOL8LLGHfxxR+PEWNdQEVTzisnOFvaSWvwwAoZM7whMPG62NMcqBXcMskT87Ymcw= X-Received: by 2002:a5d:4fc4:: with SMTP id h4mr4324127wrw.481.1644657219542; Sat, 12 Feb 2022 01:13:39 -0800 (PST) In-Reply-To: <8735ko4hwn.fsf@gnus.org> 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:226715 Archived-At: --00000000000059222405d7ce99cf Content-Type: text/plain; charset="UTF-8" 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 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 > --00000000000059222405d7ce99cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When running xlb function the code gets= stuck in a native endless loop. The patch I have added closes the fd of th= e xserver, which as a side effect ends the endless loop. Some would say thi= s patch is fixing a bug of a dependency of emacs and not emacs itself (it i= s just that emacs uses it in a certain way...).
This= solution uses native timer (using signals) to detect the timeout. Upon rea= ching a timeout it closes an the fd on the same thread as the xlb code (thi= s is because of how signals works).
To do this is li= sp we need to answer the following:
1. How to find the fd of the curre= nt 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 t= hread is in xlb native code (stack frame is deep inside other library and t= his other library was called from lisp).

On Sat, Feb 12, 2022, 09:18 L= ars Ingebrigtsen <larsi@gnus.org&g= t; 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 clos= ing
> the fd is necessary to get out of this infinite loop. Closing the fd a= lso
> causes libx11 to realize the connection was closed and call the error<= br> > handler of emacs for x11 failures for a clean termination of the resou= rces
> in emacs.

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

I don't think it would be appropriate to add a function like this to th= e
C level of Emacs, because the use case is very limited.=C2=A0 And I think y= ou
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.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no
--00000000000059222405d7ce99cf--