From unknown Sun Jun 15 08:37:05 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#63865 <63865@debbugs.gnu.org> To: bug#63865 <63865@debbugs.gnu.org> Subject: Status: 29.0.90; call-process while owning the X selection hangs other processes Reply-To: bug#63865 <63865@debbugs.gnu.org> Date: Sun, 15 Jun 2025 15:37:05 +0000 retitle 63865 29.0.90; call-process while owning the X selection hangs othe= r processes reassign 63865 emacs submitter 63865 Spencer Baugh severity 63865 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 21:55:23 2023 Received: (at submit) by debbugs.gnu.org; 3 Jun 2023 01:55:23 +0000 Received: from localhost ([127.0.0.1]:41103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5GUE-00075N-Nl for submit@debbugs.gnu.org; Fri, 02 Jun 2023 21:55:23 -0400 Received: from lists.gnu.org ([209.51.188.17]:49120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5GU9-000759-Ls for submit@debbugs.gnu.org; Fri, 02 Jun 2023 21:55:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5GU8-0000Lg-Lb for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 21:55:16 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5GU3-00088v-E0 for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 21:55:14 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: 29.0.90; call-process while owning the X selection hangs other processes Date: Fri, 02 Jun 2023 21:55:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=38.105.200.78; envelope-from=sbaugh@janestreet.com; helo=mxout1.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) 1. Under X11, with the GTK or Lucid toolkits: emacs -Q 2. Become owner of the clipboard selection by killing some text; the starting comments in the scratch buffer are a good candidate. 3. Immediately afterwards (i.e. without copy and pasting text in another window), run: (call-process "sleep" nil nil nil "inf") 4. Now other applications will hang when they attempt to paste text. Google Chrome and Slack are two examples. (GTK-based applications seem to be fine. So much for proprietary software...) I guess Emacs doesn't handle requests for the X selection when in call_process (which ultimately calls get_child_status). It is regrettable that some other applications seem to not properly handle a non-responsive X selection owner, but nevertheless ideally we'd fix this in Emacs. In GNU Emacs 29.0.90 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.12) of 2023-06-02 built on igm-qws-u22796a Repository revision: ff6163fac51759945aa619ca6bf28413be4a53e0 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: CentOS Linux 7 (Core) Configured using: 'configure --with-x-toolkit=gtk --with-gif=ifavailable' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 62487 9813) (symbols 48 9475 0) (strings 32 21897 2004) (string-bytes 1 660003) (vectors 16 9302) (vector-slots 8 148525 13706) (floats 8 32 21) (intervals 56 224 4) (buffers 976 10) (heap 1024 17392 1169)) From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 02:01:28 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 06:01:29 +0000 Received: from localhost ([127.0.0.1]:41411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5KKO-00029M-Kn for submit@debbugs.gnu.org; Sat, 03 Jun 2023 02:01:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5KKM-000296-Cs for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 02:01:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5KKG-0001uZ-Tk; Sat, 03 Jun 2023 02:01:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YewlMuWHwnmdh8nunjh6+NyVhz7DIbkBEkfS0wgxrU0=; b=hXMtKusHgis1 uZVd75k4yFBK55TlmjAq13o2QqQ9uB5AgroB9lYVe0EXv92eSqhNSbZuq+DtOwvDlVI4aplWgPgO5 gVG+vXUJBvozGSu98olO31Y43czYHhey4UfaBvfiBuEpx3P0jtQj+Mo3Ik8rDtba82sALj/wHDYMM 7Tu94nMaTOSs/lJgnYh5u6xadDwePBd7TPatb+FSHO88pai0y1maAquGIysR5SUeI+Nft1FbU3WvC kknf0txckLOatoxqwO+zSoljXDP6eGqFQxDNUxYuZB/7mN071JNM+MCaGOdGmPq0HV862P/1FGyl3 f4ckPYGAGGYrXoQYv8z4qw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5KKA-0002B4-Qa; Sat, 03 Jun 2023 02:01:18 -0400 Date: Sat, 03 Jun 2023 09:02:05 +0300 Message-Id: <83edmt9j8i.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh , Po Lu In-Reply-To: (message from Spencer Baugh on Fri, 02 Jun 2023 21:55:09 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Fri, 02 Jun 2023 21:55:09 -0400 > > > 1. Under X11, with the GTK or Lucid toolkits: > emacs -Q > 2. Become owner of the clipboard selection by killing some text; the > starting comments in the scratch buffer are a good candidate. > 3. Immediately afterwards (i.e. without copy and pasting text in another > window), run: > (call-process "sleep" nil nil nil "inf") > 4. Now other applications will hang when they attempt to paste text. > Google Chrome and Slack are two examples. (GTK-based applications > seem to be fine. So much for proprietary software...) Thanks. Does this happen also with the latest pretest, v29.0.91? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 03:11:43 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 07:11:43 +0000 Received: from localhost ([127.0.0.1]:41437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5LQM-0003wn-UA for submit@debbugs.gnu.org; Sat, 03 Jun 2023 03:11:43 -0400 Received: from sonic302-20.consmr.mail.ne1.yahoo.com ([66.163.186.146]:46081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5LQJ-0003wY-8I for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 03:11:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685776293; bh=UrGuC0N2Q4NxZRiorW/zIQSNWJr1tnv4Gwgxplx9E70=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=aElEesih5rjkIePzydQyn9iOyKHT7r8r8SXeqQPSKoY2EwirFAs8+d7qTW0hUO4PqmmfPkxccKXpKHwU6wTIWPKzqcUokJcnQJlj00vk79zVIObGM1vZXoyVxl+26ZXcTIpOTxm5wz1egQJla1cx5BM6vp0DGWU4GatVeuxdESRguxQ/oyb8xvfpedSdhcsRQa3U9VUlNoUAELC2fPmk6I0+qjBVtHCoxT/4Eo7+3aAchwS05OngMUZXoWbNgDRw65DTRWPUhGwmahLGhCO+3+IM2KbmQOwy2j2zqTki2wOh3/MGKDdqV4ghwnKcsVme5urigo21O1sWrGbtsLjv6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685776293; bh=xMEdqsXefZRbcUOIoHrNn2PC1Q/K2z4oHPBanD7VBw9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=LJaqUh9zJfWdvNTrzwEg8X+nyjQU6UlRzyjYsKMu/jt6vZ543SuAOFfi0Es1nTyFObsirW5UGL+6v8OUYJmvEXJ7BD19qZxvaHpM1couQWUnYKt75vCLl0IPANXDLCGoG/TJ5cMeoiSZ/fS2uyTNFT6YaGMxQZkDewC53mE8dX6zkv1Wa29agr6tevHagR+cX9uqBv408w2zLrjd0ZVa0jPBXXGvKKhsDNUDedjuP+qx7u6wxIob7wwenfeUCNleWCe2yzFHYxX43mKL0ju6nCc9X2UrJCyCaXKsj5FtqyRh44RIT4UyOFCopjWulqrSoXz59RmWspS/6tCqNOwfmQ== X-YMail-OSG: lgV1ZHwVM1lpSyyCB6zbFTk3XNKQg4f9quxCncGP6wy8rPaD1nmKIOBH5KkIxZn q2kiRxpAGKVfF4.sLcXuZpWLR.7pxf9p0HD4uyFLof3aKw2TCtqQxSF7ppWafhzEuwfeMqqgPQ2t S1dsgaKAIlav2MJP9FLe8HW6X0NqC2wlP8Au1x7N5UBJzH0bq.aKM_ajT5d2RtVhxyaIzn92pJOL MkrNUwWvSw2mFZXEWPcdZTKSL9Vfv47rW93xxg9W_3H55ef678_Dakgt7fk9rd.d1K_SDlYZ96pO pupdjBg0tKMqAFHB4Y2xld7BQ0Yuk9dkWBPyp2.5PCuEeDErjMHNq3V91kv5zXK6uto6tYGoxFhj iyDnDm8tsJOJcmrS4TalVpDUVgTrphSiAtVP9Xs6qQGRx9SDUY.KfL2Ekub2AORkdvAjZC8YgpTh zlOoXec0b7PKXpPr93p3ju2jn5.YgypJGh1G1_ud.ezQA09aefsx.I8uNHMGSh31yWmpgC_XVEIA DcjVb8OkY2UZmfMsF0Fq.6gOj_b.2rYbLBQ7AGXRUuDS_KDPSZtkXEj_tVdwbumW_ULbBPs3TdiI I8WuyXQBBqazUfhx.WdC0dNpAmAtwYezzVHEJfSXhjzoS14c7_UN152FXcBd8VBlyzpmrGbYgbAJ tRHQ0kthNvLxvm12cXZLHCJ5gMJMT8.3OtKLxt7vfcR4kwKF9q3K1hN4cAVl4ax5c3gbuHJI6Yak dv7UJ5nJATh4.OXuxEN00beFEUSZMq_ijTSLoByz.W9ULYlC5MPv6nXpesXKKzVoGjZTrn_kPzs4 2.z9rBbJay8u5v6uR4ihtPwIVIpl2pUHGzA3XzpX9PVvv20ZGb2Y_EMQKdLI8Wd.6WMx_sR_2zfM fGC0Z1YvAL3NoKbNGVRSJtJqY3_jExNvqSr0X49m4azdBADdkqAKMrrW6XGV5fF_LVUMUup9vAXU dhXyEMSIRaX2fdcrwrTP4OQIYkxjiPqF_kupXnWcw8eIu2NaLhIjQXzA9Gs47B.9rYwuoPzSvDUN HJlFJMZ2236pnOGO4jvcA3llhOOvA0bGXLXr.e0AdnG5gYfWYdIaMR5Jyd_QH7j5pYRznlPTTwvo faLUf5fi1u.i.uNiBF2yZMLenzkaw2smXL2Aces5oPVrEnsM1cahKvFRkWAMukjOnhQVRp.lEfFp lIR6c_ScxUf5mboyEEmzl3Zio0FXQGP4fMAv8hvQuxbbkcSQpWRdHT0_s2DgYe4aqAGXuEX1_ezi NkFIhBK.6TbNbttLLKdargphfMmnI8f1XZCmSmS1z9uVBU1bVc8eFnpEYG5SwiiwT5ofQIdMNgdG 984bGNX5NUMNFXq0EQ8_fgzwhovkcXJ1dTsi90WT631c252M04LBBNW1F3zC5Ll8e3juUuXf7RBQ uWHBKxgmv_D8n6bYG9JenQWtyBr8rJW0iwE3FFv.uQLz2VEcKLv7RMgBvF6ZR16F7Ec8dejO8Vc9 mZ2jNkAviKOQZh3krIoaYEijYRh40OK7oPNF0g0Iwp9x4ZecYjBXIA5NdmUvAZfV8h3Dmgb.TcH4 zOxQqXCzg6.ncw_HQIbTw7Xz9ObYF2gKKZ8MCJGFEm9z..RL1RTtlEcvtSEN7rAuRGJBTrEExrc9 iYpvQmL7vxgqU2e.ZUR8Imf0c9EsSnLgrocEjyoqQmu1MyONEXBtSli535mfQZgmDnf2R2rMpwUR xURin23mKhPS2kWcgBeMX0gfVuGxgn9aXUTIXWaKd9jHdUTrwlYtWRvrtkvdXEH1._ZDcV3xBdm1 _YyCKy0VHjAQ7MlwWs.JOmWtyKfhdF1hP4oKGX46axbLQR.u1qSi6E34SOKJl8N1FP3q6XM5_E_j hz87NUEtTcCBXEk4V2jAeY3r0PZpvvURMJp9vmgI_yY8ci2D4B9CQj7Ff7fzcu83qe4h9Y3Gdjz0 tTyw8ebZzVsZChFpfSwTx8RlavHH2BbrtS3jHsIuboTgxwb1B7NK4.cTSDxC_HBx2QWtid5OxBMN wIeokIWzEYC7jBK3skcOoFNxhi3GQtuSy5eU__mNzvFQipawq0STS5EuQjOxp20zG6u6ThrTiuhB In1HgPrc6Wr0MfbzzytqI.OD5NUMWV3r0mQ22D6dP1ZKbneAeqCdQKL5q8pYXXDbTcpyVIsWVh2W btT8qcSTHyUI6JaYS0axM9EqdtufttN0Q6cJ_NtrASAGfKwLXj2kx6s0MAMJ4fY6tixQ9bCzM.4C 23JJ0kTCQKEaivaODNFKeD6gAmqa.ZvN8ym6I5tly5k7gmNWy_wEOrlUz0oM6 X-Sonic-MF: X-Sonic-ID: 72d401cb-8ac4-41bd-9d2b-5738ff3f7ba7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sat, 3 Jun 2023 07:11:33 +0000 Received: by hermes--production-sg3-748897c457-fqxqz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID be49787ccd4dfbcc451b928709a2c7ff; Sat, 03 Jun 2023 07:11:26 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <83edmt9j8i.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 09:02:05 +0300") References: <83edmt9j8i.fsf@gnu.org> Date: Sat, 03 Jun 2023 15:11:19 +0800 Message-ID: <87bkhxnhpk.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 995 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Spencer Baugh , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Fri, 02 Jun 2023 21:55:09 -0400 >> >> >> 1. Under X11, with the GTK or Lucid toolkits: >> emacs -Q >> 2. Become owner of the clipboard selection by killing some text; the >> starting comments in the scratch buffer are a good candidate. >> 3. Immediately afterwards (i.e. without copy and pasting text in another >> window), run: >> (call-process "sleep" nil nil nil "inf") >> 4. Now other applications will hang when they attempt to paste text. >> Google Chrome and Slack are two examples. (GTK-based applications >> seem to be fine. So much for proprietary software...) > > Thanks. > > Does this happen also with the latest pretest, v29.0.91? I can't reproduce this, but the closest thing to Google Chrome on the computer I am currently using is Firefox 10.0.7. So would you also build Emacs with -DTRACE_SELECTION, and show what is printed by Emacs when the requestor hangs? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 05:11:33 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 09:11:33 +0000 Received: from localhost ([127.0.0.1]:41548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5NIL-00077D-3z for submit@debbugs.gnu.org; Sat, 03 Jun 2023 05:11:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5NIF-00076x-Uj for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 05:11:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5NIA-000153-Cr; Sat, 03 Jun 2023 05:11:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=s8oQZwIA56XdmF8YIYvR9KqjxShUOXOZ5S44ZuHw3L8=; b=noSE/U9jwkha 9lKwUzIrdJFVgMwqx1FqWBufRQOvJGCK2iReqWTDKZXnarB0NG7ZZ5Fu5Z77tfXZYJblvwTSfxmTR Y7aW65jQMUxKSrTg0NoY9pW2To/kvoYkWo012lXvQr8xrAjXHmjwhFJ4D0cLzUjg6q7sj1mhzog39 jw7uRMNq5EWuIA6qi2Z317KHzZBYz9WTorbJZZekin4EdjMcfH7wE+yPcCE9DwTgxCLOSKjaK8f8A DIo76uJE7iY/i/hOuNyU5Kjbb+qiYILMcEzL5FZiDI7f9u4q1KBWWx7wJ4t5QIMMoWTJ+PsA5elgP QPvMnK7itwdDgpDCFaxzwg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5NI9-0006gh-Th; Sat, 03 Jun 2023 05:11:22 -0400 Date: Sat, 03 Jun 2023 12:12:12 +0300 Message-Id: <83zg5g9afn.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87bkhxnhpk.fsf@yahoo.com> (message from Po Lu on Sat, 03 Jun 2023 15:11:19 +0800) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: sbaugh@janestreet.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Spencer Baugh , 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 15:11:19 +0800 > > Eli Zaretskii writes: > > >> From: Spencer Baugh > >> Date: Fri, 02 Jun 2023 21:55:09 -0400 > >> > >> > >> 1. Under X11, with the GTK or Lucid toolkits: > >> emacs -Q > >> 2. Become owner of the clipboard selection by killing some text; the > >> starting comments in the scratch buffer are a good candidate. > >> 3. Immediately afterwards (i.e. without copy and pasting text in another > >> window), run: > >> (call-process "sleep" nil nil nil "inf") > >> 4. Now other applications will hang when they attempt to paste text. > >> Google Chrome and Slack are two examples. (GTK-based applications > >> seem to be fine. So much for proprietary software...) > > > > Thanks. > > > > Does this happen also with the latest pretest, v29.0.91? > > I can't reproduce this, but the closest thing to Google Chrome on the > computer I am currently using is Firefox 10.0.7. It is strange that you cannot reproduce this. I thought that when another application requests a selection or clipboard text, the owner (Emacs in this case) gets called, and since Emacs is sleeping, we won't respond. Are there some other factors involved in this interaction that I'm missing? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 05:31:52 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 09:31:52 +0000 Received: from localhost ([127.0.0.1]:41554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Nc0-0007c3-3z for submit@debbugs.gnu.org; Sat, 03 Jun 2023 05:31:52 -0400 Received: from sonic303-20.consmr.mail.ne1.yahoo.com ([66.163.188.146]:46852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Nbv-0007bn-0b for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 05:31:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685784701; bh=RQNDIH1gBVjEnJZFKVJPZHC5Dc0oZ/WSbxpQyO6iWWY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=aTKuKyGNxEFiIieqsMexd+bySadRk7i/qw4J7PLS0X0Eqfean9NanNrmQ6ktf5MTLycVhxh/Tbd/6SLs6NsMvKOrCgvktspwrOYI6Efu1m7RaKWpWftQ/VmABo8jqXaDMJURVM7rN0G6348X9GhpVZzsjGHEkz6ar7u+Qyw5dzEEg7AEgEQ4Xovweji/S2YOvHj7aEkAoRQMizIUmwuDPYhFGaIyZsScnR6RK43W+8nWy52h8mcy1rJ2akGO6unrq3wGBslDmM9WsC3ZXce3dFLKT848YoxryAgCjIePQgERiJf0iPsXkTfTr3F00IrbYtnxoNOq9inBZ+4HyFyQkw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685784701; bh=EnhI7sBvUqbgXvyjYXGO3Vi8+TIKBSVY91tCMskanqH=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=V1+GHPpX+ESUPteVHFytNXnD8RxXuRfQcILCExYcujNXhCV/ToG51E7jTKNiFOUyboLpqPPZDQQZOVBoxlTDXLtkkMdD1KVM2w90nnDg2P5RGrEAWpQh9+qQiniExebuNO0jaTdTcPvYUWhiE5ALY5XMbn5VkMDPgMu7ISNr8FR7Lc2SbUWe6c4HsQR9aXUiY0qU9Sy8InhheqbLjo13B7NemC6JUpT765fvOUGkXi/6LG50eenLlWX/3SQpNariXOo712oaSEXV7Hvq1NqXp5As53w7UvnjYBua1GBYQEhTGvkGiaTKiUQk4UO5vhEQO8Tz+ALZrxcIeiXSn+bX1Q== X-YMail-OSG: TSVcQbUVM1n0vCFvgN7tNpxVm7rtxoo06kUraZskHa_QmXqTHrn1dfSlgdHpyuw 1CAM4UBJhFwogtqcORehiAakSvz6TRafaRKs.U8BvHRhfFA5_a3VF8ZHhfui6sHOn2Fbp6OreXzW 31nUj3WoEKHfQSoZoXmHK4DXCdpxXacYA_KRKOwoj4JDB0vUScSb_tY3uXm5m47WuvIfUiTQRwPp eFpPQZrEh8Xsk9FhHOcq5V12Wx7yjcsMyv7By9toLsPDeU_gkhIlo2lGGXDMsNN8gSNkkzBjc_ow UPoHcLoAzdDr1QrI96i47cbONZpglKhxtGSPDzAsGyWQAnf8b955IzEXF_rxi32Sg.6AldCAUlOc 8K3dswoqWZp9jz70n5jekPuA8pX8gxxwq_YHVDC8M9Ws9gtMIGgipQZehCXmOQ3Ho3a6ovoDhBFB qYO2yufaY64xYGoOvj_d4YYO4ZQcDhErpvU7E85mLtETCtsn5pWMAidoHDp.fk7o2nrigeO1MswF VDX2m8NUVNDWOWNSfJmMbTIEVVAwffUlwg.dPXlO1nvT.MjtGW42YzUfRgalQ2Ba617SHT9GisXU HrpLQ1ob9FH3yTJpxMcGd2z5dag6gjA2.n7nqptsEwjS6IIaW_TxpI2iFM8nUwyNSt6qzMGgGVz8 wx0rg5iGu.wBJzEize2KicEHn9yD2rD9YtwBL_BgqSDoXIZG3FvA6bJlhEjr8WCwUOBoRkeBmNwS vtqq0vvfYUqOhtHSmf62BX3T8rbJcVEA0pQKHmNL.8rxb_cB.FORNMBDX9zijgyiFudg4VVr0ckY xxtZe2gO2L03okwpQP3jW1Fjj6iWC0sWuaWzG.KtVJOGvwVTbTqwDnjICQVATtFWp86EvJGKIUHv fJl_EJThjZwpKdIp57WOxuqYStUcb12xOwc38.R6o9TTH9RKAEfEwHgpk_LexwBzVGNy_19LQKx5 JjUdH4fbhgUvzI2S1rb66rGyr6sVHFVXzS2LfzfkQEHnQh0dTstQI.m2hlutYa4vJY0oRUWc1eFN jK6dvjdst1Qkwuil55NvEY4g26.qMkebIBVGA93DzzHd9OvKCmLdTCcBIZ0JXHnvDyMHRaJ6l7LS 6AGVJp07nt_EvYVWM9jvKoK6J4PrEGWmyZKSnAiGgNllNyA1rq1la5Az2OQOfq5zDC4KZxYspNdu PwBPIRdGCsXvJfNR.EAGEEPoRx3Ow9HECrk3KuDhcebmPU78AOunsdz7pS9bCc_pCCVTmiAE0dkN ycmT3AHjemTkW.W6G64O6YX2K4PS2FqmX1zRD9wSYeWHjCC5LRCQ6NIPDGCNZyEwXXZZGCRTOehw KpfFTq0_2AHuUt9hhr1z7R3zW0ttpNoDzbF2iSelN6myUpFh7nQZwjOMSl3Bfm0WBI3h0oo1MClD LmdqvqzPTbtKkGFreJnbZ25G3Ke1iUtxjAA3zTIRUtXnz9RlMY3oJYG27hVUeOxKeVBwca0M8.x6 hZozOUgJo0F6Mb9TAhbUPLlWk3gwofVuhMkt8hALMwKrQkuzCHmxY.FVzbn1ChFD.C2_Hv3Nhbjc YDwI4mpct1kfRGENzw414rNNRUGBRH0GZdkCGDgzPihJD3w2QMyXpkztrRkMzPuok7_.UvRWLP0Y jLXwsOJWliFTyO2sLxrzAw3toVTM7_6XzmJ1WcUkU6NNAc7hizLp87T5K66_K6mnFuqaaUq00Arq uaE57yCEDI1wax.mTvNYtMdnx4lXAFFy.O1DVgToXz5K1EA3KLmrmtsOk_qsqRzQcQ2voqkK_0TG haD85lpWoizdwy0FpHUf6A5EW2do3U_WgRwxNtqIROuCSbpmmzmjO.O3VGqBtfTdfPaBB.HPKxj5 zODBOUTORMAGmOIxsDJ0NrI2npMl.htd5X72T7LJwxYzWTZD_A3MA5YHcJxjwHszi71BahzIPC4v 0tSozsE0L53cmg0fpQB_e9RoxM_vsTYtcWZ1sTj_A6YSfeAiQ7rwjF3E22U.kZUpBQ5tt05CbyFV DE7trJkRlHLNkGzAiL9SEc4YCi1Op9JIAkblPFH7Yao3eYfBaXNL4ZrfRV.7tOqsHO09UtHISulR 1EZPxnwBR4l4vTzDPySuMe1jKuPxDYDC1T0PO2GaYCcDnKCGfGRY6tfvVYNNAPU.WexnqrMygyh9 4tLe_DwqwyUW5Asij7Ebcd6znfQVcjfyjlzYuImRSliPmh2vWW7ZfNOHlXyRxfA12lEdrhsupdRN CLjPaEIrsF.EBXg73JGQP28xhphik.mfKwwtS5wta8kWCtgmn2Yhy_75Ho_ZV98NtqA-- X-Sonic-MF: X-Sonic-ID: 48172ecb-fd85-4cf1-8bde-4c30e1b9c298 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Sat, 3 Jun 2023 09:31:41 +0000 Received: by hermes--production-sg3-748897c457-524hn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1dcf248134aa7cfd6895260e77c93033; Sat, 03 Jun 2023 09:31:37 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <83zg5g9afn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 12:12:12 +0300") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <83zg5g9afn.fsf@gnu.org> Date: Sat, 03 Jun 2023 17:31:30 +0800 Message-ID: <874jnoopsd.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 558 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: sbaugh@janestreet.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > It is strange that you cannot reproduce this. I thought that when > another application requests a selection or clipboard text, the owner > (Emacs in this case) gets called, and since Emacs is sleeping, we > won't respond. > > Are there some other factors involved in this interaction that I'm > missing? In this case, the requestor should time out and give up (which is what I see.) It should not simply freeze. So my guess is Emacs is responding to the selection request in some way that confuses the requestor. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 07:10:48 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 11:10:48 +0000 Received: from localhost ([127.0.0.1]:41634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5P9k-0001sD-7F for submit@debbugs.gnu.org; Sat, 03 Jun 2023 07:10:48 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:57645) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5P9i-0001rz-BI for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 07:10:46 -0400 From: Spencer Baugh To: Po Lu Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <87bkhxnhpk.fsf@yahoo.com> (Po Lu's message of "Sat, 03 Jun 2023 15:11:19 +0800") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> Date: Sat, 03 Jun 2023 07:10:41 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Eli Zaretskii writes: > >>> From: Spencer Baugh >>> Date: Fri, 02 Jun 2023 21:55:09 -0400 >>> >>> >>> 1. Under X11, with the GTK or Lucid toolkits: >>> emacs -Q >>> 2. Become owner of the clipboard selection by killing some text; the >>> starting comments in the scratch buffer are a good candidate. >>> 3. Immediately afterwards (i.e. without copy and pasting text in another >>> window), run: >>> (call-process "sleep" nil nil nil "inf") >>> 4. Now other applications will hang when they attempt to paste text. >>> Google Chrome and Slack are two examples. (GTK-based applications >>> seem to be fine. So much for proprietary software...) >> >> Thanks. >> >> Does this happen also with the latest pretest, v29.0.91? > > I can't reproduce this, but the closest thing to Google Chrome on the > computer I am currently using is Firefox 10.0.7. BTW, this can also be reproduced using just Emacs. If I try to paste in another Emacs instead of in Google Chrome, I get a hang, followed by: gui-get-selection: (error "Timed out waiting for reply from selection owner") With -DTRACE_SELECTION on both Emacsen, the selection-owner Emacs prints no logs, while the pasting Emacs prints the following log: 48866: Get selection UTF8_STRING, type _EMACS_TMP_ 48866: Start waiting 5 secs for SelectionNotify. 48866: Waiting for 0 nsecs in addition. 48866: Got event = NO 48866: Get selection TIMESTAMP, type _EMACS_TMP_ 48866: Start waiting 5 secs for SelectionNotify. 48866: Waiting for 0 nsecs in addition. 48866: Got event = NO > So would you also build Emacs with -DTRACE_SELECTION, and show what is > printed by Emacs when the requestor hangs? Emacs prints nothing while stuck in call-process and the requestor (Chrome) is hanging. After I interrupt call-process, this log prints. 48290: x_handle_selection_event 48290: XGetAtomName --> NULL 48290: XGetAtomName --> text/plain;charset=utf-8 48290: x_handle_selection_request: selection=CLIPBOARD, target=text/plain;charset=utf-8 48290: XInternAtom text/plain;charset=utf-8 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 70 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 70 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 70 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 70 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=TARGETS 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 92 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 23 elements directly to requestor window 48290: x_handle_selection_event 48290: x_handle_selection_request: selection=CLIPBOARD, target=UTF8_STRING 48290: x_start_selection_transfer: transferring to 0x1600000. transfer consists of 70 bytes, quantum being 16777112 48290: x_start_selection_transfer: writing 70 elements directly to requestor window From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 07:15:39 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 11:15:39 +0000 Received: from localhost ([127.0.0.1]:41654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5PEQ-00024R-Nx for submit@debbugs.gnu.org; Sat, 03 Jun 2023 07:15:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5PEO-000246-U2 for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 07:15:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5PEI-0005q1-HK; Sat, 03 Jun 2023 07:15:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8dSm1Uc5tEhWx2CzA72duI1YDgEgsgkeqi6bgmbCE/A=; b=WoM6IB6BAm1V CzYzHiC5V38YAelBHqWCfYUa2dy452CBscBxF21s06QNPkMn2TkkvHl//dzNEGTiZDmHXE3CQLvPl 2mdcNtTmhpmPuKFH37hsbcZBa1Aez1i/01wWEip5hl9rQKjNStIPWk9DuNp4wW0yTMY37UCIMBmfi 9/mgqr8AKeoe7/zOJoWPqAeHVTSpXB+oNkpzp6OifDdVde95FUW9oAwoZup6DlNaCJFh7kMf1QtWT k2f+w/KQC0jrxNCe4DjoBuWYF2n1ngha0DE3cJuHu8vpk4yRqy+zKxSQKBf7mJQHcsT3gt40iCMNB 3KZ4NbakcUCXlVRcAYtTPg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5PEA-0002Si-1R; Sat, 03 Jun 2023 07:15:30 -0400 Date: Sat, 03 Jun 2023 14:16:13 +0300 Message-Id: <83r0qs94oy.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 07:10:41 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Eli Zaretskii , 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 07:10:41 -0400 > > BTW, this can also be reproduced using just Emacs. If I try to paste in > another Emacs instead of in Google Chrome, I get a hang, followed by: > > gui-get-selection: (error "Timed out waiting for reply from selection owner") Isn't this exactly what is expected to happen in this case? Po Lu said, in response to my question: > > It is strange that you cannot reproduce this. I thought that when > > another application requests a selection or clipboard text, the owner > > (Emacs in this case) gets called, and since Emacs is sleeping, we > > won't respond. > > > > Are there some other factors involved in this interaction that I'm > > missing? > > In this case, the requestor should time out and give up (which is what I > see.) It should not simply freeze. And that is exactly what happens when Emacs requests the selection: it times out. What else did you expect? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 08:07:51 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 12:07:51 +0000 Received: from localhost ([127.0.0.1]:41753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Q2x-000083-5c for submit@debbugs.gnu.org; Sat, 03 Jun 2023 08:07:51 -0400 Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:34518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Q2u-00007k-HV for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 08:07:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685794063; bh=ekrRgSvsUTC/kTqrzSD6LQF4S4SJ5LVWu7Z0EQWvx2M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=c1F8fodOdY5Zd24cJFZ2XYZCYlKpbfeIFvnD/LJVuPIG627eVXeEdJIncQnfLsDd4U6pphKFH3/EMfJfdHBj1qhPHU3TMfBJGo7tZprnWKdRENvBpMknApJKhvnpcBiO27vrQ9/Dmw3MvbumaZ1+avruljZMebeezo0sRtPtTQGiOSWYLL2Jz2agNKaFpXu/uc+lF2QtcssIgforsBvPbVrcbZFX4Byblk+von7je25mFwvPUzuZwcXmTTOwI5DGGz3r0I/mKwhE1/7N1ppvc8ACB8P3VsFFqZKIXqASiEsAv5SKet4ZHsJhyK4W0Ytw1giGiKgeVErkX4C+bYDnqw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685794063; bh=rlbXCdwY0uMG0OmAKX2sDTn1xLtpplM02YMvQt82nT0=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=girBXQD7c0VZJmbp7LBZ6k1MG3dhF0Ba+RlZ6eglYc0Lb/ersXbAh1MOPI/u6BebzbwnY/XOXuEXT3BSAvyfnc+yvWYGQ/rCbBERsVJRH9Gjn9N+jV4kSzbkOcPrz9rgV7Npqz97uE6udFZk2ayTm8xo5Eb2AGbWH8/2KMkonjVpT1kdeZXQDa5TF0FYRp6yKV2PaPLAKxbumP9Sqt+YMuO2a5m/lh8doitwsbqA3CpZon6LbncsDnNfdGFWRueNHgpHIMPDXK+3Ya8aXPAXsGzXEnGYvijht6r0pfcgjhGcGmj3+oVcvrND0f8jyd+jGCAS/ufbbAut532AqumZ8A== X-YMail-OSG: TYzryggVM1kzp4gr5r2NrJ4nUvYAFiCCrv7uw5fPGc5jXXbrLI8eCX68wP1yaMK 9tTAS5I.VA7YN_fMLmLntWz0OcvElRZUnbQt0wi4TMxHDchxAq7esJUU1ccVDJOECGtOlJqoKxY6 t7KLkEZCWd4l4l.bp9yEND3x8Ptr_3NAWu1MOlBPSluSnKhd7P1qtJ70KxMkTidWdcEmfOaFjIs. i2QPX4bUBkXQUoulrdJ4weyA8ip6zbKhChs79ItKLcQVtW5_sGIV1wMelWwngsXfMNB7xAeoI7si e3Ph6ACN9MlsxiCCGSenOa2dLN6bcAZt8AKyOWnlLx6ulFJRnw.kcPKevrHqEzbewltus.B0St5j 7bz0JbcwID0CTv39iuCqr.q4Z3sG83FCVT4RxtrkeUhAKBS2.V_zh1qgn.p3t77FF3vutwM2mYdH IGImJ0L836yz6wRlkNbqWtPoHCje_Q_JbaZm2P67RyFlHR70wFTGxLcBwCMvuTNBSIKN1s3B_ZN8 XqJIDlN4A8UlJkmXq.8c5lla7PvyakKcraL7bWZxPMdVfWXV.D7LBpMWAXzz2vPoNQtxY.ozSyq. g5MIVMAaFDqEMSfa0tvaIlIkE87Px.j52Sybhx_TEnobPjMxHYFvisSIGS1ZpNn77A7HyxBzw1Np 7cTp83RSbJOLviF4.n0V8u0OVFZobtHsCoGyDxigMo7yhQzm8FgOgtgILCYDPL3C9.We2.OO3ArN M7l1Pw6aA2dh3RULyWhkdu49y5CO3pNAZLF0sXwkIeDKv6rAq_l7Lg0x.JmTBqMDqATf9ybQp0o2 IhmWwGnf1K3Zm51WxUan3Nhq_zu3.b4ixLHd4ZjFdJSJSc5JCTpkZ2hrPQ7IItnlboj.MvviGtF9 fMXZpq4iWjU4gl4MbC_h._GgmNg4_l9Wbs.rXmas1wGE7uRMnDSuqhrlXf5fgpxmAtXn0i88m.vn U1a.S6GhKwvYZRLXghbZeOuY0TGvUJZfURWjy1mm2x_XrOHLtt0sy4ea7408.0b7DPqM7ehyP7yu ooXtcTPw5uI1QylCGBNgo25s4y4IR6kjjS6NtG2ziOLP9iXXUz1ckMJvqq3CslwV9CkJuU9wDADR Vw1YDh9FBWG5.Zl1DswU5rI2moq3UI20DQFOdxF5bBl7rXncjjTpM2kCNpGzHr4.APyMwYKGdU6A N4p4If8vZLjMSCvf8V_bFk3HCofJRLvDmx3w4L17fcjmB7PHMd4Y.mG3fsGn6IJ.d_.oNo8rwctE wQPENOSopDKW7W2GDJI40kCJfvIi7nL76IRU8vUAFR90dYW5wklodRsir6Ku2o2_EwY2LfKc6i23 sgSK_8GWFdKrOn9wq2QEB2F7GFAyqYL_rusfTfalaPbHXMWEQtaiiIbUvT2xIC3FVZe7Dz4qI3vf h2FiiWEaNqKPvk.Rd1pkdw66MNlDrWIfM_emIwW_KWk3QOodedSEzFoanqQ6EkBQLpAM1xQMbbDX DJ7CaA6rY0TUhp5U4AEkjW4tKmMIZI6WeotF.dz7XFGdFHQ2uwMufzmTFFkErk1BJ1E6QpXwTPbx UzWsB8xzVmGZJMNOY4b8vZ04GIJa1gUQY4jIxptoW0C_23BmboXBlsYHtpx6DTRXjvYgcdCyBzCT _PG0bVsisA3J2KaqPp3aWXudMTN1Zr05gjv52d__d9I2cIMTdDxN8nLGBinkuXdhg3lJq1j5aPlB nwETNQyKLE.Cb_qP2iahpPmSOm4NCu8WyUwzphKPSwj1KMWWPqX7DCyrhXsivMSNW6rcIje7j3uu Mn2YcMIkPODFkLVCywTW.kwTOS.8nhwJqqJBf_byabGRNUAnpp0S73J0YNzTjs1vTFwvTqCKcU2V Nrfc84wKb8UafkpNvLTwVUfv.VDuXjRUcVaDTMaxAgIITnytK1yqFArzUf_MrsZtGiN2OjlLh6hf mRpZAIpii807aVJTJNFN0Qq2l91KDagRVYNMfJjJkHHCHYFPTa_YkfyNFtx4HrATncp66hybg446 DRx.eXv7FkqmLX8YvW2GfxYt3SRWtXXTRpBXhUPez7xwI5uoO9VpJu7bEAvK4uGfduVFs9uVLDYl YxzlTVsVOwh_V3mY2DH50mY1uR3eeBVALogleRiGFgARpvwg0A2x8E_n11V75TWfNga7Kwh2ESiy i2CxyX_rqKvpzPJ4fjAcuErZcT7K6vNVbdlkTlBfPMu9vs9TasXBo_qHoErZvrWdRl2kEkQSz2vS g8d2mdjosN2reV0ZTqDu6.i0XZ1J750PkOS8Qg60vMOCyeSc0qmCXv3zJ.sYr.ofnlA-- X-Sonic-MF: X-Sonic-ID: 0e4c8958-bc1d-4456-968c-890ee46c89a9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sat, 3 Jun 2023 12:07:43 +0000 Received: by hermes--production-sg3-748897c457-24pr6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0b9e54814892f91cdd4d32a36c3c2e68; Sat, 03 Jun 2023 12:07:40 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 07:10:41 -0400") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> Date: Sat, 03 Jun 2023 20:07:33 +0800 Message-ID: <87wn0kn3zu.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2094 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > Po Lu writes: > >> Eli Zaretskii writes: >> >>>> From: Spencer Baugh >>>> Date: Fri, 02 Jun 2023 21:55:09 -0400 >>>> >>>> >>>> 1. Under X11, with the GTK or Lucid toolkits: >>>> emacs -Q >>>> 2. Become owner of the clipboard selection by killing some text; the >>>> starting comments in the scratch buffer are a good candidate. >>>> 3. Immediately afterwards (i.e. without copy and pasting text in another >>>> window), run: >>>> (call-process "sleep" nil nil nil "inf") >>>> 4. Now other applications will hang when they attempt to paste text. >>>> Google Chrome and Slack are two examples. (GTK-based applications >>>> seem to be fine. So much for proprietary software...) >>> >>> Thanks. >>> >>> Does this happen also with the latest pretest, v29.0.91? >> >> I can't reproduce this, but the closest thing to Google Chrome on the >> computer I am currently using is Firefox 10.0.7. > > BTW, this can also be reproduced using just Emacs. If I try to paste in > another Emacs instead of in Google Chrome, I get a hang, followed by: > > gui-get-selection: (error "Timed out waiting for reply from selection owner") Emacs doesn't hang... > With -DTRACE_SELECTION on both Emacsen, the selection-owner Emacs prints > no logs, while the pasting Emacs prints the following log: > > 48866: Get selection UTF8_STRING, type _EMACS_TMP_ > 48866: Start waiting 5 secs for SelectionNotify. > 48866: Waiting for 0 nsecs in addition. > 48866: Got event = NO > 48866: Get selection TIMESTAMP, type _EMACS_TMP_ > 48866: Start waiting 5 secs for SelectionNotify. > 48866: Waiting for 0 nsecs in addition. > 48866: Got event = NO > >> So would you also build Emacs with -DTRACE_SELECTION, and show what is >> printed by Emacs when the requestor hangs? > > Emacs prints nothing while stuck in call-process and the requestor > (Chrome) is hanging. OK, but then this is not a bug: Emacs can not respond to selection requests when it is not reading keyboard input. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 08:31:08 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 12:31:08 +0000 Received: from localhost ([127.0.0.1]:41769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5QPT-0000ki-Ji for submit@debbugs.gnu.org; Sat, 03 Jun 2023 08:31:08 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:37639) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5QPP-0000k3-0n for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 08:31:06 -0400 From: Spencer Baugh To: Po Lu Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <87wn0kn3zu.fsf@yahoo.com> (Po Lu's message of "Sat, 03 Jun 2023 20:07:33 +0800") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> Date: Sat, 03 Jun 2023 08:30:57 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Spencer Baugh writes: > >> Po Lu writes: >> >>> Eli Zaretskii writes: >>> >>>>> From: Spencer Baugh >>>>> Date: Fri, 02 Jun 2023 21:55:09 -0400 >>>>> >>>>> >>>>> 1. Under X11, with the GTK or Lucid toolkits: >>>>> emacs -Q >>>>> 2. Become owner of the clipboard selection by killing some text; the >>>>> starting comments in the scratch buffer are a good candidate. >>>>> 3. Immediately afterwards (i.e. without copy and pasting text in another >>>>> window), run: >>>>> (call-process "sleep" nil nil nil "inf") >>>>> 4. Now other applications will hang when they attempt to paste text. >>>>> Google Chrome and Slack are two examples. (GTK-based applications >>>>> seem to be fine. So much for proprietary software...) >>>> >>>> Thanks. >>>> >>>> Does this happen also with the latest pretest, v29.0.91? >>> >>> I can't reproduce this, but the closest thing to Google Chrome on the >>> computer I am currently using is Firefox 10.0.7. >> >> BTW, this can also be reproduced using just Emacs. If I try to paste in >> another Emacs instead of in Google Chrome, I get a hang, followed by: >> >> gui-get-selection: (error "Timed out waiting for reply from selection owner") > > Emacs doesn't hang... Well, it hangs for 10 seconds, then times out, because Emacs is correctly implemented. Some other applications are incorrectly implemented and never time out. >> With -DTRACE_SELECTION on both Emacsen, the selection-owner Emacs prints >> no logs, while the pasting Emacs prints the following log: >> >> 48866: Get selection UTF8_STRING, type _EMACS_TMP_ >> 48866: Start waiting 5 secs for SelectionNotify. >> 48866: Waiting for 0 nsecs in addition. >> 48866: Got event = NO >> 48866: Get selection TIMESTAMP, type _EMACS_TMP_ >> 48866: Start waiting 5 secs for SelectionNotify. >> 48866: Waiting for 0 nsecs in addition. >> 48866: Got event = NO >> >>> So would you also build Emacs with -DTRACE_SELECTION, and show what is >>> printed by Emacs when the requestor hangs? >> >> Emacs prints nothing while stuck in call-process and the requestor >> (Chrome) is hanging. > > OK, but then this is not a bug: Emacs can not respond to selection > requests when it is not reading keyboard input. "Emacs can not respond to selection requests when it is not reading keyboard input." sounds like a bug to me! Even if it's hard to fix, it's still a bug. If I'm implementing some package and I decide to use call-process for some long operation, then some user uses my package and it runs call-process, and they get bored while waiting and switch away from Emacs, they'll experience a hang in some other application. That hang seems clearly undesirable! (I should mention that Slack (and possibly all Electron applications) have worse behavior than I originally said: They don't just hang on paste, their UI hangs completely while Emacs is in call-process. (I guess these applications are constantly requesting the selection or something?) Which is an extremely bad experience for the users of packages which use call-process...) I'm personally working around this by replacing call-process with start-process and accept-process-output. Because otherwise my packages (and any other package using call-process ever) will cause random hangs in other applications, which is obviously bad and not something anyone would want. So perhaps call-process on Unix should be reimplemented in terms of those functions? Or if that would change behavior too much, perhaps call-process should be deprecated in favor of some new helper built on those? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 08:54:25 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 12:54:25 +0000 Received: from localhost ([127.0.0.1]:41783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Qm0-0001PS-G8 for submit@debbugs.gnu.org; Sat, 03 Jun 2023 08:54:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Qly-0001P1-E3 for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 08:54:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Qlt-0006EN-5z; Sat, 03 Jun 2023 08:54:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DpvFwaXO9KSKL2QhvExkt40Z/PNQbEMbwgdL1gqRm5M=; b=TQf615/LgGjS 8QhkeMneGZRgRaWv3toqlML1+uHTZdDGfOWK+J2Wc5fbkSuGeonhkpZDZd+2Bw1oUkoXFw0J/nDih eiwBTmPwbqR2JE1Fqm7Adpwym6w+KU/q3WPIXHN25br3vOUwZVoxUX/PW0Dsv6P8xr4/gH/ttM/7z gbNACxqke65UuBjwYY1Eu6H1WuwAKQPAapPzUEWDRcWbJcbAaARXPV3zF1eBTt2SFeHptBDlt0uTX nIRsshp2gdotOhUfXcryE0wyqfWGjMnqISHyFIOMYtiAWXQFcKwdfMWG6TJbb70FcEVGwUUXlRmKo TiRD7/fVxRDgx0bZQVTmFA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Qls-0004fg-In; Sat, 03 Jun 2023 08:54:16 -0400 Date: Sat, 03 Jun 2023 15:55:07 +0300 Message-Id: <83mt1g9044.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 08:30:57 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Eli Zaretskii , 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 08:30:57 -0400 > > Po Lu writes: > > > Spencer Baugh writes: > > > >> Po Lu writes: > >> > >>> Eli Zaretskii writes: > >>> > >>>>> From: Spencer Baugh > >>>>> Date: Fri, 02 Jun 2023 21:55:09 -0400 > >>>>> > >>>>> > >>>>> 1. Under X11, with the GTK or Lucid toolkits: > >>>>> emacs -Q > >>>>> 2. Become owner of the clipboard selection by killing some text; the > >>>>> starting comments in the scratch buffer are a good candidate. > >>>>> 3. Immediately afterwards (i.e. without copy and pasting text in another > >>>>> window), run: > >>>>> (call-process "sleep" nil nil nil "inf") > >>>>> 4. Now other applications will hang when they attempt to paste text. > >>>>> Google Chrome and Slack are two examples. (GTK-based applications > >>>>> seem to be fine. So much for proprietary software...) > >>>> > >>>> Thanks. > >>>> > >>>> Does this happen also with the latest pretest, v29.0.91? > >>> > >>> I can't reproduce this, but the closest thing to Google Chrome on the > >>> computer I am currently using is Firefox 10.0.7. > >> > >> BTW, this can also be reproduced using just Emacs. If I try to paste in > >> another Emacs instead of in Google Chrome, I get a hang, followed by: > >> > >> gui-get-selection: (error "Timed out waiting for reply from selection owner") > > > > Emacs doesn't hang... > > Well, it hangs for 10 seconds, then times out, because Emacs is > correctly implemented. The value of the timeout can be customized, if you don't like the default. > > OK, but then this is not a bug: Emacs can not respond to selection > > requests when it is not reading keyboard input. > > "Emacs can not respond to selection requests when it is not reading > keyboard input." sounds like a bug to me! Even if it's hard to fix, > it's still a bug. We run Lisp to generate selection response, so there's no way we can do that when the main Lisp thread is busy. It isn't a bug, it's a restriction of how Emacs is designed. > If I'm implementing some package and I decide to use call-process for > some long operation, then some user uses my package and it runs > call-process, and they get bored while waiting and switch away from > Emacs, they'll experience a hang in some other application. That hang > seems clearly undesirable! Then don't design the package such that call-process blocks Emacs for prolonged periods of time. Because this will annoy the users of Emacs even before it will be seen by other applications that request X selections. > I'm personally working around this by replacing call-process with > start-process and accept-process-output. Because otherwise my packages > (and any other package using call-process ever) will cause random hangs > in other applications, which is obviously bad and not something anyone > would want. > > So perhaps call-process on Unix should be reimplemented in terms of > those functions? Or if that would change behavior too much, perhaps > call-process should be deprecated in favor of some new helper built on > those? call-process has its use cases, which are important, and we will not deprecate it. You can easily emulate call-process with start-process if you need to do so, so Emacs gives you both possibilities (and expects you to use whatever is right in each case). From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 09:10:11 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 13:10:11 +0000 Received: from localhost ([127.0.0.1]:41793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5R1G-00020R-VS for submit@debbugs.gnu.org; Sat, 03 Jun 2023 09:10:11 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:42333) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5R1D-000208-R3 for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 09:10:09 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <83mt1g9044.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 15:55:07 +0300") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> Date: Sat, 03 Jun 2023 09:10:02 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> If I'm implementing some package and I decide to use call-process for >> some long operation, then some user uses my package and it runs >> call-process, and they get bored while waiting and switch away from >> Emacs, they'll experience a hang in some other application. That hang >> seems clearly undesirable! > > Then don't design the package such that call-process blocks Emacs for > prolonged periods of time. Because this will annoy the users of Emacs > even before it will be seen by other applications that request X > selections. Forget other packages: Emacs itself uses call-process in tons of places where it will run for prolonged periods of time! In fact, I just ran "C-x p g call-process" to search for instances, only to find that that command itself uses call-process and hung my other applications! Should we port all these instances away from using call-process to avoid this behavior? I certainly would like to, because I don't like that when I do a particularly long process-find-regexp or shell-command or any other operation which uses call-process, it doesn't just hang Emacs, it hangs basically my whole OS. >> I'm personally working around this by replacing call-process with >> start-process and accept-process-output. Because otherwise my packages >> (and any other package using call-process ever) will cause random hangs >> in other applications, which is obviously bad and not something anyone >> would want. >> >> So perhaps call-process on Unix should be reimplemented in terms of >> those functions? Or if that would change behavior too much, perhaps >> call-process should be deprecated in favor of some new helper built on >> those? > > call-process has its use cases, which are important, and we will not > deprecate it. > > You can easily emulate call-process with start-process if you need to > do so, so Emacs gives you both possibilities (and expects you to use > whatever is right in each case). What use case does call-process have on Unix, which an emulation in terms of start-process would not also satisfy? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 09:48:20 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 13:48:20 +0000 Received: from localhost ([127.0.0.1]:41902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5RcC-00034i-5L for submit@debbugs.gnu.org; Sat, 03 Jun 2023 09:48:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Rc9-00033t-CD for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 09:48:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Rc3-0008Cc-Re; Sat, 03 Jun 2023 09:48:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=oqDm9P1bBewJnDEP+SUBOXsgNDTa+XsrG8L/f9YLGwU=; b=PaebKwlDWEb7 Q0eXBtQN/rYJGaziY/3JyvOCgsGvRwHz88LZkeBdwvR2BHoNL49sINMn+j8Vn1JNmif93eOS3lTeO 1rHYp8atmolEissq52ZDOdO2V+Rvb7M/MXs415UCuAf3r1kyPXRgSI/uEqGM5I5kqmBF9ZDsnHDFq pco88+L5XyhHUE8tzz34CsXSXEzy5dVuA9GSR8MxUU27nXEUZqOt0ViDy98C/AaFdmxrLEaIqzgHo gqY0E4RehG67rUXA8ja2mxWixPtHX9ttvUkEErXhPhal5vYoh8bSXDsfu2wrcRuX2vfiAMwRlNfUV k6J+CdStU/o53nKCBEUt+Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Rbp-0004bA-V9; Sat, 03 Jun 2023 09:48:11 -0400 Date: Sat, 03 Jun 2023 16:48:48 +0300 Message-Id: <83leh08xmn.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 09:10:02 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 09:10:02 -0400 > > Eli Zaretskii writes: > >> If I'm implementing some package and I decide to use call-process for > >> some long operation, then some user uses my package and it runs > >> call-process, and they get bored while waiting and switch away from > >> Emacs, they'll experience a hang in some other application. That hang > >> seems clearly undesirable! > > > > Then don't design the package such that call-process blocks Emacs for > > prolonged periods of time. Because this will annoy the users of Emacs > > even before it will be seen by other applications that request X > > selections. > > Forget other packages: Emacs itself uses call-process in tons of places > where it will run for prolonged periods of time! Really? "tons of places where it will run for prolonged periods of time"? what is "prolonged period of time" for this purpose? Aren't you a tad exaggerating? > Should we port all these instances away from using call-process to avoid > this behavior? There's no general answer to that, we should examine each case separately. > > call-process has its use cases, which are important, and we will not > > deprecate it. > > > > You can easily emulate call-process with start-process if you need to > > do so, so Emacs gives you both possibilities (and expects you to use > > whatever is right in each case). > > What use case does call-process have on Unix, which an emulation in > terms of start-process would not also satisfy? When the process returns quickly. call-process is significantly simpler to use than start-process+wait, so doing that when unnecessary is a complication we shouldn't take. Anyway, this kind of discussion doesn't belong in a bug report about X selections. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 10:12:52 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 14:12:52 +0000 Received: from localhost ([127.0.0.1]:44063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Rzw-0004Hk-0f for submit@debbugs.gnu.org; Sat, 03 Jun 2023 10:12:52 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41901) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Rzq-0004HT-UA for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 10:12:50 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <83leh08xmn.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 16:48:48 +0300") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> Date: Sat, 03 Jun 2023 10:12:41 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org >> Date: Sat, 03 Jun 2023 09:10:02 -0400 >> >> Eli Zaretskii writes: >> >> If I'm implementing some package and I decide to use call-process for >> >> some long operation, then some user uses my package and it runs >> >> call-process, and they get bored while waiting and switch away from >> >> Emacs, they'll experience a hang in some other application. That hang >> >> seems clearly undesirable! >> > >> > Then don't design the package such that call-process blocks Emacs for >> > prolonged periods of time. Because this will annoy the users of Emacs >> > even before it will be seen by other applications that request X >> > selections. >> >> Forget other packages: Emacs itself uses call-process in tons of places >> where it will run for prolonged periods of time! > > Really? "tons of places where it will run for prolonged periods of > time"? what is "prolonged period of time" for this purpose? Aren't > you a tad exaggerating? "prolonged period of time" is anything over a second. I see tons of calls to call-process with potentially long-running programs. "find", "gcc", "grep", "awk"... and depending on the user's system, *any* subprocess call can potentially run for a long time. But again, the point isn't just that they can potentially run for a long time. It's that *the user's whole system can be unusable* while they run. We are not just blocking Emacs, we are (sometimes) blocking *everything*. >> Should we port all these instances away from using call-process to avoid >> this behavior? > > There's no general answer to that, we should examine each case > separately. A general answer could be fixing call-process to not hang other processes. >> > call-process has its use cases, which are important, and we will not >> > deprecate it. >> > >> > You can easily emulate call-process with start-process if you need to >> > do so, so Emacs gives you both possibilities (and expects you to use >> > whatever is right in each case). >> >> What use case does call-process have on Unix, which an emulation in >> terms of start-process would not also satisfy? > > When the process returns quickly. call-process is significantly > simpler to use than start-process+wait, so doing that when unnecessary > is a complication we shouldn't take. What I mean was an emulation like this: (defun my-call-process (program &optional destination &rest args) (let ((process (make-process :name "call-process" :buffer destination :command (cons program args)))) (while (accept-process-output process)))) my-call-process is missing a few arguments that the real call-process has. But if this is all I use, is there *any* reason to *not* use my-call-process on Linux? There is at least one strong reason to use it: It won't hang other processes. > Anyway, this kind of discussion doesn't belong in a bug report about X > selections. But the entire point of this discussion, for me, is to fix the X-selection-related hangs which Emacs currently causes when in call-process. i.e., this bug report. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 10:23:33 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 14:23:33 +0000 Received: from localhost ([127.0.0.1]:44087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SAH-00073Z-1I for submit@debbugs.gnu.org; Sat, 03 Jun 2023 10:23:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SAF-00073M-90 for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 10:23:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5SA4-0002by-J6; Sat, 03 Jun 2023 10:23:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zo+rCzV+j1jgDbAw+doJXD4CtUEXfxVlqQRgwLzsceM=; b=SMMmuTCjLzc8 e3Ar9xF1VZySK9knkNkd1hqPgj7SV4++NV8yd9/c9s7Otu2dtzGa/zxsqsBCiEBUrJxnFmTVd6ScD zJgPaId9epRyoeOarVFeRmJ6idbmyDFLYOAVUojLgdP3N/NlB8pKNZIL3yiQ8quj/A7Q/NniP0MUj /DBmS+2HT0k5YhyGb0/I6osD6yDBf7Yv+YX0MbV/TWCWn7wrTEEJwa2bMhxDstAWFL7UAKlFfLA5H F24lefoKW+DZwyxn1s7zVAw2UjuQ3Pyqoa6/A+/+5gv0l3ILB8G4Cn6q/0zB2/WhcpF91zOOpEFdl hU+bZt5Nhod23PfZGhLhHg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5SA3-0005qr-U8; Sat, 03 Jun 2023 10:23:20 -0400 Date: Sat, 03 Jun 2023 17:24:11 +0300 Message-Id: <83a5xg8vzo.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 10:12:41 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 10:12:41 -0400 > > Eli Zaretskii writes: > > > Really? "tons of places where it will run for prolonged periods of > > time"? what is "prolonged period of time" for this purpose? Aren't > > you a tad exaggerating? > > "prolonged period of time" is anything over a second. > > I see tons of calls to call-process with potentially long-running > programs. "find", "gcc", "grep", "awk"... and depending on the user's > system, *any* subprocess call can potentially run for a long time. Please be specific. For example, "grep" runs in an async subprocess; we run it with call-process when we probe it for support of some command-line option. If you can show that these calls take "prolonged period of time", please describe what you do and show the timing. > But again, the point isn't just that they can potentially run for a long > time. It's that *the user's whole system can be unusable* while they > run. We are not just blocking Emacs, we are (sometimes) blocking > *everything*. AFAIU, the only "everything" that is blocked is an application that happens to request an X selection at that precise time. That should be rare for short enough call-process runs, since the same user is doing that. > (defun my-call-process (program &optional destination &rest args) > (let ((process (make-process :name "call-process" > :buffer destination > :command (cons program args)))) > (while (accept-process-output process)))) > > my-call-process is missing a few arguments that the real call-process > has. But if this is all I use, is there *any* reason to *not* use > my-call-process on Linux? You are free to do it if it suits your needs. Emacs provides those primitives to you. But saying that this should replace call-process in each and every case is a non-starter. > There is at least one strong reason to use it: It won't hang other > processes. Yes, and gazillion complications, like handling the SIGCHLD signal, pselect interface, etc. > > Anyway, this kind of discussion doesn't belong in a bug report about X > > selections. > > But the entire point of this discussion, for me, is to fix the > X-selection-related hangs which Emacs currently causes when in > call-process. i.e., this bug report. It doesn't matter, because you insist on making the issue much more general. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 10:41:25 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 14:41:25 +0000 Received: from localhost ([127.0.0.1]:44108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SRY-0007Ww-Ri for submit@debbugs.gnu.org; Sat, 03 Jun 2023 10:41:25 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:34541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SRV-0007Wd-3B for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 10:41:23 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <83a5xg8vzo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 17:24:11 +0300") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> <83a5xg8vzo.fsf@gnu.org> Date: Sat, 03 Jun 2023 10:41:15 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org >> Date: Sat, 03 Jun 2023 10:12:41 -0400 >> >> Eli Zaretskii writes: >> >> > Really? "tons of places where it will run for prolonged periods of >> > time"? what is "prolonged period of time" for this purpose? Aren't >> > you a tad exaggerating? >> >> "prolonged period of time" is anything over a second. >> >> I see tons of calls to call-process with potentially long-running >> programs. "find", "gcc", "grep", "awk"... and depending on the user's >> system, *any* subprocess call can potentially run for a long time. > > Please be specific. For example, "grep" runs in an async subprocess; > we run it with call-process when we probe it for support of some > command-line option. If you can show that these calls take "prolonged > period of time", please describe what you do and show the timing. No, I mean "grep" called specifically by call-process. As, for example, I see happening in mh-grep-execute-search and nnspool-find-id. In the former case, it's a recursive grep which could take many seconds. Or as I already mentioned: xref-matches-in-files (used by project-find-regexp, C-x p g) uses call-process-region to run recursive grep in an arbitrary directory. Which could easily take minutes. These are understandable designs, and I'm not too bothered by the fact that they block Emacs. But this becomes much worse when they are also blocking other applications because of this X selection bug. >> But again, the point isn't just that they can potentially run for a long >> time. It's that *the user's whole system can be unusable* while they >> run. We are not just blocking Emacs, we are (sometimes) blocking >> *everything*. > > AFAIU, the only "everything" that is blocked is an application that > happens to request an X selection at that precise time. That should > be rare for short enough call-process runs, since the same user is > doing that. No, as I mentioned earlier, some (buggy, of course) applications frequently request the X selection; such as Slack (and possibly all other Electron applications too). Such applications just immediately hang during the entire call-process run without any user interaction. In my case, Google Chrome and Slack are the only non-Emacs applications I use. So... for me, everything gets blocked. >> (defun my-call-process (program &optional destination &rest args) >> (let ((process (make-process :name "call-process" >> :buffer destination >> :command (cons program args)))) >> (while (accept-process-output process)))) >> >> my-call-process is missing a few arguments that the real call-process >> has. But if this is all I use, is there *any* reason to *not* use >> my-call-process on Linux? > > You are free to do it if it suits your needs. Emacs provides those > primitives to you. > > But saying that this should replace call-process in each and every > case is a non-starter. > >> There is at least one strong reason to use it: It won't hang other >> processes. > > Yes, and gazillion complications, like handling the SIGCHLD signal, > pselect interface, etc. > >> > Anyway, this kind of discussion doesn't belong in a bug report about X >> > selections. >> >> But the entire point of this discussion, for me, is to fix the >> X-selection-related hangs which Emacs currently causes when in >> call-process. i.e., this bug report. > > It doesn't matter, because you insist on making the issue much more > general. I would be happy with a targeted, specific fix for the bad behavior I reported. Here's a specific instance that would be good to fix: If I run "M-! sleep 30 RET", that will cause some applications to hang while Emacs is waiting on the sleep; sometimes (as with Slack) without user interaction, or sometimes only if the user tries to paste in them. Do you have a suggestion on how to fix that? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 11:01:50 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 15:01:50 +0000 Received: from localhost ([127.0.0.1]:44121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SlJ-0008A1-Oh for submit@debbugs.gnu.org; Sat, 03 Jun 2023 11:01:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5SlI-00089m-7o for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 11:01:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5SlC-0006qs-JY; Sat, 03 Jun 2023 11:01:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RGz+2gXiInYH8DtwGPcIsWr5LnyDq3rODI5Z57khEIY=; b=Mdpqh0C9gfvt kTsl5fiw59dlCQ0DGryxAiznCrYTEdA2tQ0bgigdigFnLHbl2QDnxbNIih67DdFrQGbNXpyd9pI9M FvsZnM2a6VdcX1V9nzGdMuzpAI/lkkmB9UN/P7crolnM8n8Zd4oc0p5LBiNhvWMyXU92jG2UxFWUp aIpqIS9AZ4hYhUbIcjAurZUznWwoaxjdPSxc109CCBH9cYZJf4lMMMhMkS854XguznFmM/rf29TJm GsNuDQ745ftjbguvv9N+KJIbYIc5wH1c/FLD/wxWm61LlFIgBCsHvk6GWuujRKWY/MLVwAvAABkDK tt4vbY7w0+W9E2ddX9cczw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5SlA-0003qk-DV; Sat, 03 Jun 2023 11:01:40 -0400 Date: Sat, 03 Jun 2023 18:02:31 +0300 Message-Id: <835y848u7s.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 10:41:15 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> <83a5xg8vzo.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 10:41:15 -0400 > > Eli Zaretskii writes: > > > Please be specific. For example, "grep" runs in an async subprocess; > > we run it with call-process when we probe it for support of some > > command-line option. If you can show that these calls take "prolonged > > period of time", please describe what you do and show the timing. > > No, I mean "grep" called specifically by call-process. As, for example, > I see happening in mh-grep-execute-search and nnspool-find-id. In the > former case, it's a recursive grep which could take many seconds. > > Or as I already mentioned: xref-matches-in-files (used by > project-find-regexp, C-x p g) uses call-process-region to run recursive > grep in an arbitrary directory. Which could easily take minutes. I hope the respective developers will consider whether it is reasonably feasible to make those features non-blocking. > These are understandable designs, and I'm not too bothered by the fact > that they block Emacs. But this becomes much worse when they are also > blocking other applications because of this X selection bug. Only the buggy ones, let's not forget. The non-buggy ones could wait without blocking, just like you expect Emacs to do. > > AFAIU, the only "everything" that is blocked is an application that > > happens to request an X selection at that precise time. That should > > be rare for short enough call-process runs, since the same user is > > doing that. > > No, as I mentioned earlier, some (buggy, of course) applications > frequently request the X selection; such as Slack (and possibly all > other Electron applications too). Such applications just immediately > hang during the entire call-process run without any user interaction. It is unreasonable to expect Emacs to solve bugs in other applications. We are having hard time to solve our own. > I would be happy with a targeted, specific fix for the bad behavior I > reported. > > Here's a specific instance that would be good to fix: If I run "M-! > sleep 30 RET", that will cause some applications to hang while Emacs is > waiting on the sleep; sometimes (as with Slack) without user > interaction, or sometimes only if the user tries to paste in them. Do > you have a suggestion on how to fix that? No, I don't. And I explained why at the very beginning. I invite you to read xselect.c and see what kind of processing we do there to handle selection requests. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 11:34:54 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 15:34:55 +0000 Received: from localhost ([127.0.0.1]:44136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5THK-0000e5-KM for submit@debbugs.gnu.org; Sat, 03 Jun 2023 11:34:54 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:59549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5THG-0000ds-Kc for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 11:34:53 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <835y848u7s.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 18:02:31 +0300") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> <83a5xg8vzo.fsf@gnu.org> <835y848u7s.fsf@gnu.org> Date: Sat, 03 Jun 2023 11:34:44 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> I would be happy with a targeted, specific fix for the bad behavior I >> reported. >> >> Here's a specific instance that would be good to fix: If I run "M-! >> sleep 30 RET", that will cause some applications to hang while Emacs is >> waiting on the sleep; sometimes (as with Slack) without user >> interaction, or sometimes only if the user tries to paste in them. Do >> you have a suggestion on how to fix that? > > No, I don't. And I explained why at the very beginning. I invite you > to read xselect.c and see what kind of processing we do there to > handle selection requests. What about a new version of call-process, maybe "call-process-allow-lisp", which doesn't stop timers/process filters/Lisp/etc from running while Emacs is blocked in it? Then any caller which doesn't want to stop Lisp from running while they are waiting for the subprocess can use "call-process-allow-lisp" instead of "call-process". I can implement that if it sounds desirable. I can also send a mail to emacs-devel if you want more discussion of it beforehand. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 11:49:31 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 15:49:31 +0000 Received: from localhost ([127.0.0.1]:44141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5TVS-00014F-3S for submit@debbugs.gnu.org; Sat, 03 Jun 2023 11:49:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5TVO-00013y-0E for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 11:49:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5TVI-0007II-Fv; Sat, 03 Jun 2023 11:49:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9Xtw/dIN5E3fe7LHONCkT643HtJrECTfhb6jjX3y6H8=; b=nU54+MZcZ212 YREO/5CI4FnsS6UeIdfKxDX3hxMWDgmj4hHvT9spYwKjREl+lhGIazEqFWS4uLbEE8vG9mRoRhkIv sIWbbXGNVxAsxBRyy4L0O36pZDL8C+gQpyyMqhaDgo6UK4xz6zbtWHrEs2wPX175MFTamOHF177Bo SMOlsLpoIVBce09tBYmgR38n2HWW4Tsy2OoFPE4lFblLd4rqNc33Cf3qKyPOllvaO6c98MKHB1vI8 WNEzo+MnxDKHi63FfdOujKY2e0cQGGmoWLU/S2fI35gPw3Qk3v8SZuhs+PU9slmLXbmceNF3ZwSiC hpJqlbBxp2LRo/0XKiwxbw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5TVH-0005Yx-Tc; Sat, 03 Jun 2023 11:49:20 -0400 Date: Sat, 03 Jun 2023 18:50:11 +0300 Message-Id: <831qis8s0c.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 11:34:44 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> <83a5xg8vzo.fsf@gnu.org> <835y848u7s.fsf@gnu.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: luangruo@yahoo.com, 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 11:34:44 -0400 > > What about a new version of call-process, maybe > "call-process-allow-lisp", which doesn't stop timers/process > filters/Lisp/etc from running while Emacs is blocked in it? Then any > caller which doesn't want to stop Lisp from running while they are > waiting for the subprocess can use "call-process-allow-lisp" instead of > "call-process". If "Emacs is blocked", timers and process filters cannot run. So I'm not sure I understand what you mean here. if you mean to use start-process instead, then why exactly do we need a new function? The building blocks for coding that are already available, and I very much doubt that you will be able to come up with one-fits-all combination of them anyway, because of the different needs: what exactly should be blocked and what not, and how. > I can implement that if it sounds desirable. I can also send a mail to > emacs-devel if you want more discussion of it beforehand. Yes, please. This discussion doesn't belong here. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 12:21:07 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 16:21:07 +0000 Received: from localhost ([127.0.0.1]:44172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5U02-0001qn-V3 for submit@debbugs.gnu.org; Sat, 03 Jun 2023 12:21:07 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:42867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5U01-0001qe-AE for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 12:21:06 -0400 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4QYQ8v6xP1z1r4py; Sat, 3 Jun 2023 18:21:03 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4QYQ8v4ySZz1qqlS; Sat, 3 Jun 2023 18:21:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id SltcomDxwmuT; Sat, 3 Jun 2023 18:21:03 +0200 (CEST) X-Auth-Info: Am64Bo4KhezXDfnbOXpAzQL4bGZ2QaA1Cm6H4j7P+x3Loanull+2t42FKLfkpGRD Received: from igel.home (aftr-62-216-205-144.dynamic.mnet-online.de [62.216.205.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Sat, 3 Jun 2023 18:21:02 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id B18A82C1DD9; Sat, 3 Jun 2023 18:21:02 +0200 (CEST) From: Andreas Schwab To: Spencer Baugh Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 09:10:02 -0400") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> X-Yow: Give them RADAR-GUIDED SKEE-BALL LANES and VELVEETA BURRITOS!! Date: Sat, 03 Jun 2023 18:21:02 +0200 Message-ID: <87leh0wm8h.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.4 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) On Jun 03 2023, Spencer Baugh wrote: > Forget other packages: Emacs itself uses call-process in tons of places > where it will run for prolonged periods of time! This has nothing to do with call-process. Emacs can be busy for many reasons. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 13:03:23 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 17:03:23 +0000 Received: from localhost ([127.0.0.1]:44229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Uew-00080Y-UJ for submit@debbugs.gnu.org; Sat, 03 Jun 2023 13:03:23 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:51781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Ueu-00080J-AC for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 13:03:21 -0400 From: Spencer Baugh To: Andreas Schwab Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <87leh0wm8h.fsf@igel.home> (Andreas Schwab's message of "Sat, 03 Jun 2023 18:21:02 +0200") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <87leh0wm8h.fsf@igel.home> Date: Sat, 03 Jun 2023 13:03:14 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andreas Schwab writes: > On Jun 03 2023, Spencer Baugh wrote: >> Forget other packages: Emacs itself uses call-process in tons of places >> where it will run for prolonged periods of time! > > This has nothing to do with call-process. Emacs can be busy for many > reasons. Other things which make Emacs busy still let Emacs respond to X selection requests. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 13:06:19 2023 Received: (at 63865) by debbugs.gnu.org; 3 Jun 2023 17:06:19 +0000 Received: from localhost ([127.0.0.1]:44234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Uhn-00084x-Ee for submit@debbugs.gnu.org; Sat, 03 Jun 2023 13:06:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Uhk-00084i-Ur for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 13:06:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Uhe-0003cE-01; Sat, 03 Jun 2023 13:06:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FEKF5SifCMZJWsInVXHP+0wKOSPfhVcVnktxYjfGGLc=; b=MAoYJTTkiKHN YhMFoVTTi14Rx6RvUWQf0SSC6Tf/Qr2mU6tnGzH509p3AxYdKi73681II6diVbpkJK5zsxE0Xp3/G GmNifIWotFcgftIIFH5oGLtf+Maa2avrSDII7F8V73rhDj0vcy9sl8DgjiKVUK+bRgB0GSsyKEVYo KK1NF9e2ocWwIM+mN+dshJ+SowlsFrPWFntB2QMuj2xv+ciHYjZDL9p+5WStPBkKUrRTwSjK/I3AW HGKhrfefaB38cnC2OEojbTU8Gysq3HZT2ANQ0ISlY7kbdlmJAweuat97RsquDIJJSILvREksiG8JS DblzFi+/B/iUclZMLjzLTA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Uhd-0004Nd-GN; Sat, 03 Jun 2023 13:06:09 -0400 Date: Sat, 03 Jun 2023 20:07:00 +0300 Message-Id: <83ttvo79vv.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 03 Jun 2023 13:03:14 -0400) Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <87leh0wm8h.fsf@igel.home> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63865 Cc: luangruo@yahoo.com, schwab@linux-m68k.org, 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: luangruo@yahoo.com, Eli Zaretskii , 63865@debbugs.gnu.org > Date: Sat, 03 Jun 2023 13:03:14 -0400 > > Andreas Schwab writes: > > On Jun 03 2023, Spencer Baugh wrote: > >> Forget other packages: Emacs itself uses call-process in tons of places > >> where it will run for prolonged periods of time! > > > > This has nothing to do with call-process. Emacs can be busy for many > > reasons. > > Other things which make Emacs busy still let Emacs respond to X > selection requests. Which "other things"? Andreas is right: anything that the Lisp thread does prevents it from responding to X selection requests, because while a Lisp program runs, Emacs checks the input queue only occasionally, as part of maybe_quit processing. So when the main thread is busy by doing anything, all bets are off. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 20:12:56 2023 Received: (at 63865) by debbugs.gnu.org; 4 Jun 2023 00:12:56 +0000 Received: from localhost ([127.0.0.1]:44511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bMe-0002Sq-E5 for submit@debbugs.gnu.org; Sat, 03 Jun 2023 20:12:56 -0400 Received: from sonic316-21.consmr.mail.ne1.yahoo.com ([66.163.187.147]:44568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bMY-0002SV-KI for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 20:12:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837565; bh=JcBGPOTb2ty/ptV5YNdIGmJuuucPEkx6cMAJYGZF9C0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=nmfWfe+JSBAYuHV3wxLLbt5Z0iPbgy5u3akHaJPXIahp7tO8l58bujOOUf331hTxaDN1rONp1vPeOgYJZpacKwpEmYtz31grBnYiSI9mulgNPOy8NrVpBOptI+lzN1bN7QleYruTx8Sy4nTDEDb8ODdKI50nFWlaKpXh8trdfkIqGOfZEo4SPpbbK7hfAOFkISjXz/GK9IX+tCkus4sSS583AfM+AnPwwXo0Mdxce/bgv/wAWi6ovCg61q/6mJWKU+h0Z/PuYcl60hKtmJ7KknS8sp4hdK5myHDbfuCv+IAWKzgnKoW+/4XEtKlJJrWrY/FvO5x4iEQyPsuoa/qDBQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837565; bh=De8adGY8ePxzBGt7q5wnSeQ2seVsnLdmbOvxmnRVR2Q=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=oAoudJIQZEIDveYKYnhzdIoBz85kJD+Xqt2dGmORqi5i6poW0AW2zyq2OiktyvvdQbDGwRmkr/8zSMO1D34s/itmK4mgZg4trURcxmUG+eYB/5eBwt5rGX++rVyVWEaT0aCeHVGyuuRkIQZ6rmfYALjXvKbe+P2vMgIM27A9AKmo4g/GrQP/WQusgTkWP5tCKycCsW0QU54otIwN4s2PN/fFcHO/22vKmBdb3W1SB1iRymP6hYjG2lkVYy+GGurcUEQkhArkYxz62gsqtXnxxLP2E9GfQbTAWplH4hKUKcELjkfi0ox9SBurofQKAvMCPUcsB79G0/xTPz/XsHRzTQ== X-YMail-OSG: XEz50QsVM1lzExU98RldnrcqQXOc49bkGa9OScUVjdIWqwjpbz46Gwt6kMa4Nqj ZTqOBXh1Yeqsz9fjt6DMVyA4PofV46Ui6uxcaRq53ZBN.__55N5t0bPIhbt6TOWLeQKg2F2qQeLp aWiGfwaT.hhUnPFO3TrjsMYxtRi.5beRUf57zvnbxCLg8wI7VJFayCm1bLgJXeCF9MFwRyWj0vJQ iEPs1LDHjQXylbAwu.9nWj36FUSXLRizWayZ4xufPT_lU8oemCwUuxNtFogDJ0VV7EHtLCPfRa9g 8EV9BIEorjxfBmKMc7IAvRHO_FaMKbdsgQw.ypCGYxfFH8.okZFhiT0WHIpt46LvTYMp8AcjCgJf n3MKt3ieaarECVBzYUaUQlhPXh3cFY33yPidji_C9jufdUp_DIezoBkZk.5mmyYoGmgV_OC.h0lf IulqvX8L5xVXJFG7L4Y1fZfSfGxh78VcIXXrbszZimqRahBWVuvER3HIQpv3n7BprtnIT6N2nDVh s1wUjZ5.l027r8oNDDDUeJmvpGOnNvq2TZ7.q.3QvNwfbl4mOkmD8exCt_0eEj0adV7Wav9Ea5f0 fMGbzyz1fYtjk3cS2VspdGlS7xOf6PcUzhQe2u5cKetl6_eEEcxzAPT_Tcf7aFZWqcMTk_p0N6k2 yS.sZNiKXo.y1t0b4Z5gy1l1t5Hb5T67BlIEDoFgZOIKuZhxIj1_EfSbelBaKjwmvCbOdYr2nn2q re4XYeBrfJS4_aLhtRYBYLhun9VeCwHk_Fri4O4Itt46pUQdp2VQzbiTpqeSydWAUo9TQNQxF8Z4 hKEWbuer5eVAFNzBBp194xeT7vl7H57AOZ6e5Gf9.ZlbkbhakFlT1m3tad8m9KzhKxLUDCaw8CiA JrPA0OwfLUe5.hXSPxtiz4g.mUl7f_wgPeTCTZyH9c.GveIdUMYMHq.p6BTBFuYtNxq.7gNehWd_ taVyQwwr81_d_nBFga1ipoUJo5Dig3XCQtRoA0o9vUUc1OLdSiEd3lRC7CAgWe3qCF2s62huXDp. tQ4N1zEN_b7wQDLDnrL90Nasid2gquqQOQvlCqdPnMrCqXofpCUDi9sX23amPksIhQr1c304lvHb qE8WixhiDDtAGtRK_JD0DfCdJ4rSGTDkcTsLJHKEQrE9jLW0iwciBNGEFZ_F6me2qz9mQFsXiwiw uSOMeGdiGKpcp5Kjmh.tc25aXqd3S4TdKIB3s4jaiZYrfcqJzZ4ydwPS.vL647OMKQHsdKGjE72v 1HHdRtZL9XGeCw85nDPZr78j3o0NVqYmG7ctqYDpbrJzEV4_4V76wU73nX.ziGStb33OnOlG1k7w U61sotgoc2yG0okoU7r11biE6yj3KXQ0EBB.zEUBXQGsfLFYFXlr5kJGKffDD_khbcq7cpavNnYo K5CZXtxAFZtFJfgNMNr360Mk8WeOROUp6RxG8hHD6c74nXHu_KTBqtUxZsQ9FjTucHDzVd_gik4q a7Iel0dJzEFlZHQtA2pYSJ0UQsazc4VRqAqU.uzMz6.nLe7sCjGs7ywxwgBuAK7BXlUIMR33Am6b H3jDPsq5kAlQBOEjwCu.NHfAISaRJFs7vHIcjGHBHWoONro4grIXaQWIA9dBpa55wqtfMgytJcks zSTqdTkSbinWyjRW3yu4v5wv6NhUvGLDPQppEKe8fzf7a2iW3c2CXrWXEcOoiHn2VfHLSfypex3I 1AaDuyFfdLe_bF4znBbC3Yae1vbGEQlBNU4i9IRBzH3axipxyDAbDFyYlB6TWUDCq01ouqSFAZXd GOIMLfdtThUf87y3SBYAenb4uP1dU2QFP3WHLt2YNugrJIE6rAcmOWqFur.1CGnWIUVSPb9iqddv jNSZxSkGSfvkr8EVRHi6BjvV0.yScrAAMgkV0EBsJmOghOalf_YsnoQtGh02zcTNeJCVB8Gg9Rhm UnBa35aljWdLdqhvqzVw2qe2qOMKUES_VBuRGLSoeCVI7zqV8qGwExoE4zGOcUx9d._7xZMo_0U6 kf0QL8SvJihpsInSVGOD0MqXVIPGAGa3u13O0LKIr8te1MOrVQbYkxDXl0dUUT810sjxWYNoz2.L uYfYj3EAgQ5zgwAlsmGDVFm0J4gGOZ0EqE7gWz._8DMFhGa1pKol4mG_T4PQ_XayGlGAnkC8hhML aoC45L72UGe51HRpzQLk3c91837ZqVZuFUeOv3HBOwPUlVyVRP6GUQsicXldHLQxUHaOVIK4T3g9 JDiVB0Ucd9x.TCy.X.QNkPXOjFejaHo0P0WROXcxHyEzb2Tojw8cAwM.V74a6P7Icec0- X-Sonic-MF: X-Sonic-ID: e7e90793-fa28-4921-8792-bf907f8813b4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 4 Jun 2023 00:12:45 +0000 Received: by hermes--production-sg3-748897c457-524hn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5a9c7772353f7991842daced8076beb0; Sun, 04 Jun 2023 00:12:41 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 08:30:57 -0400") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> Date: Sun, 04 Jun 2023 08:12:34 +0800 Message-ID: <87sfb8m6fh.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1792 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > "Emacs can not respond to selection requests when it is not reading > keyboard input." sounds like a bug to me! Even if it's hard to fix, > it's still a bug. > > If I'm implementing some package and I decide to use call-process for > some long operation, then some user uses my package and it runs > call-process, and they get bored while waiting and switch away from > Emacs, they'll experience a hang in some other application. That hang > seems clearly undesirable! > > (I should mention that Slack (and possibly all Electron applications) > have worse behavior than I originally said: They don't just hang on > paste, their UI hangs completely while Emacs is in call-process. (I > guess these applications are constantly requesting the selection or > something?) Which is an extremely bad experience for the users of > packages which use call-process...) > > I'm personally working around this by replacing call-process with > start-process and accept-process-output. Because otherwise my packages > (and any other package using call-process ever) will cause random hangs > in other applications, which is obviously bad and not something anyone > would want. > > So perhaps call-process on Unix should be reimplemented in terms of > those functions? Or if that would change behavior too much, perhaps > call-process should be deprecated in favor of some new helper built on > those? Do you expect completely arbitrary Lisp code (which may perform _any_ operations, including reading user input) to run inside call-process? Because Emacs runs such code upon receiving a selection request. Hangs in badly implemented programs are a small price to pay for such flexibility. Try getting a clipboard manager: it may resolve the issue. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 20:13:53 2023 Received: (at 63865) by debbugs.gnu.org; 4 Jun 2023 00:13:53 +0000 Received: from localhost ([127.0.0.1]:44516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bNT-0002UK-TJ for submit@debbugs.gnu.org; Sat, 03 Jun 2023 20:13:53 -0400 Received: from sonic302-22.consmr.mail.ne1.yahoo.com ([66.163.186.148]:40998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bNP-0002U3-RW for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 20:13:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837618; bh=d1U35+YocGW/CF+xMRh5ZZCqKFSck3W484Wmo7V17nQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=CpFbxJWpJ3fvpmmIoWAxx3ep1W6Ql8I0LNL2XhsE9fZf3cuELfhipSuaAA3SUgQQM8TlLAbvV0P/sQV9tutS3Gue2Dol1PHEgmo2He/40FA+3CEIKKMscDnhI1ZzcQ9lzKvqJcuWnYmUmxI0q/VNXB4503d/7Tr25+ainaOlYwa8PZF5UVoA353klCAWniTdrSUeGDsaUfocxZJh4ZrArlMIwQrZYInMAAa78FskyaDA5PlS5cio8G7uDaWY4uo0CLJQ9fu1HyXJwptjePeCl3JHKeNJtSpsHkGDVuxLCEHpQARZMeJUbammwQHsWispuQZ4xs2HwDs+HS/tVYKMXA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837618; bh=JTs4NT5ERm11tRBupAGpuSiBL5kEKTeu5Z00fXutN4h=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=O5oi+DvZdr1CpOP7IgfUF1btVH6P4S9GiQEDMzBXoYlv4WIro18L33TtSN62Syep5Hv8K1eL7pgACZJWVcFJDL7QoHpnaMPGgdGC0AZMjT5Ihh0X4J9SL0EvH6NcoYCV2Odnw1hSd4YX/9jKMtzdGj3ENnGEz0iCag770MXkHx68R9QWXrcHU5HhAoSm+k1s6c1pXoBKsK2/ZK2pTupLYw0COJi0VwcXx5zPOo0Lhba7j/iN2ERBLrP8ZwtkRW+LDbkJYVpoP6by4ukfiNUrF0YB/6g0Cjg3QEY0IegAxaGYUZ1ey0MHm5xGNkeCffdNjTO4AW2QliYJ/CfbTHtKpg== X-YMail-OSG: conL4B8VM1mtnWUB8EhgpTe0HxXFL1zAvZYSBwKbQKEMwZcufjE4Cqse6QPmGtY DTEChHFIx.7X8OsmC8oirFMPCg.5rjq.kCFFRhONat2aHCfAov5ZetG4slyktizRwx2f.CaV1B.K XANtBoozo8uDQfQ9B6u.m.W_vXTOeI6r6YuPP2anZhgU64UtCUGj8px5aBiws2ufugQnZMx9SRrr smAL3.JtrMTPNqAWKwRxCCpbDwHHfLnkfVQGw9ygfSYhjaW5ixf3ImjMVUDul2DnNPIWhQfmnUyu zEWhGBM.7i_uTdvTPx3srs0xOK2S27ezwiCrAQa3CYhjnES0D75767Sypg3ypx0.V18NC7Ar5kd9 DD93Wmo3cPjjfsh3KvfxjomobzS5xJJNfHcNe5wRNqMs2p7moB5cGnz2iecN4A8PzBT35085tXSv w0ClWC58RrHAf2P.VIu6DhVN_l8_onpWMD.CLzmX1sN.EJvWvmW9tT5LGeFd4nYh7dIB4Me22502 5Y8.b4ezbxUc9qXYAfSSkD3toXxjIIicFczcDgQV8JCZdajewkV8TVi1Tw3x2FGZeDDkxTuo3vI6 AyoWKFZkC0PHdhsNQNEb2IpWbNQzDOiquBc53X77v_XZ2zYvF8u1T0nFkFm446j447JvvHIMHB0o aEpvOohNmdsYUk_twnhKX0gjR4E86x4PDSMa3nrtjhCZ_AxZ8xD_9RqpvfFz4ZQLtjlKHCCPMtzS E7AF0wckOvSTbsV5elj0rpbk1pOZF2PCnNVexftu3m.UdCjwGk4UrejDirTqsD7Qp..wp1owi4yC MPSYTZrxmHXLMVzIhj3MXLqQyqMV0kPeXK_7QjYCXJMRd2upGNz2HauR60LzeVEfzXj.Q6iRYN4U lETsZnnVkhi1TSKS8ceKJjdy.g317y9oDsmatUKzY37M6KAcwvEUxXcNt9zg3DtHwRgTbx3dak2f dBSbvtsZDBl8hQgpNfK_Svjy_vxd0C3zmjgwTUHWzTjhjohz3uNk6Yj3eYWsyPAzlfrCsWHIuscf AWV1g6CDK.upTLRbS2kAtWeY8QdAl_r2Q9OkGC9tT5nHphuBXqSbK.3_Lm1UMSVd5qoyRN1pRdoR IrvLQnji8UFk6pgNPLnU3va0XyVBzSgpMU5N_xXpcNgDlzzMu_6R5H53VWm9hwP95coL1Uc15TJG Im6SE9Palm1ctuSsp_7SY6MLfg5DwxqWF2tQVMMnnn6Hggm7L08sgh_E1DQAleEjQmFc9GY5.5g6 l_xqVeP22lRXkSPaS2kwj.muq6ZMcmu9WZIaBKKfm2AQu6m7fvV4Wb2oTFjDURhBcooO5SdRMwHr ZhsHVcfbbHflx_KtfA3AoZOC_d1eVOz4SEQ0JMH.iHCqeVGVzHvftFYLO4hW6FOZVVktiIwf0k.b shtdHAoVz7NJkqppqPjtuXB.rqxXURgHcRC1Gz0apuVNR1Q677ygWxdgkZE4u44X519Ad5PKipC2 mjXUIdOR9r3c0E0l5nYiBc5ofQaBZn0ryr0TN_ghFGWhlCXFYlTdCfIojj_Y1mDOkfwwUeSzd.zj dJwolWEJNe4m3KaFvxrfZnIyTYSLp7vn2Xvzkg4qNjENUHklg2LfTXeZPPVPjcR5Tm6Ao6SKNjFD x.7KqCD0P5fTz92f1LIXz4cnNBSlBLQOhovSgeOeENKzzjtndOrENob_SpjwjbMQgWuu3g2A4E.T 3DIrojF1YXW6tw.CVG6w0TawrUiucRr9LjTOoeYn3V1KGKchIjlmyKT0maNRzMzZJENEHn2ruIES LXMNMAI21xbqu4bwvE0Vjyc0_j.gICuAOeaHy6ooIVgc2.p.T0ILIbO5as.0jx29M_kBm41.9KSU mQeDcSU9dQ_PBq978jk7dq9RRn4QqsH5jRdyTgAcuT.3uB47DY_T6WQ_VAkqjD7Ibm_VS.ZGOXxm EpAqCkEH_jMyjwOdW5_nqwGDN6RSAf_mS2Q7pujZnYkE8E4GTAuhpBy7SKmUTyGk6o98iF6Ru0ts wFhZqEJ_m4p1WVv4pwclSfqAGrVL41rvsVOF9XZJS8XRbW5.WMWK1NK36OAqsd1WvQ8yodkRVKeW 0tfsnNBspzUFRXrRIzzCU8ug05k1ls3lgfSaujsucw1zGDqvlD94CcbpudkbtbplLLwnjCTKm6jV QE5CQqOfDtUdUbFfWBfIzfVTtw4mq0xYjl_VKxvQfJG6oaCGzJc.0fKxJvPPdeCd6plOXLa8JD8q IdilTNnkbz7H27q4dA3c0K8SotJEDTZzn3Bh_tSyENSJELORv.25cA34dbasqWW.p X-Sonic-MF: X-Sonic-ID: ad9692cd-4e1a-40c3-a06a-587dfe770e9e Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sun, 4 Jun 2023 00:13:38 +0000 Received: by hermes--production-sg3-748897c457-5chhg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bda28e4ca84b22c055e870e27ef88e11; Sun, 04 Jun 2023 00:13:31 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 09:10:02 -0400") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> Date: Sun, 04 Jun 2023 08:13:27 +0800 Message-ID: <87o7lwm6e0.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 205 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Eli Zaretskii , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > What use case does call-process have on Unix, which an emulation in > terms of start-process would not also satisfy? That random Lisp does not run inside. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 20:15:22 2023 Received: (at 63865) by debbugs.gnu.org; 4 Jun 2023 00:15:22 +0000 Received: from localhost ([127.0.0.1]:44522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bP0-0002XW-GV for submit@debbugs.gnu.org; Sat, 03 Jun 2023 20:15:22 -0400 Received: from sonic316-21.consmr.mail.ne1.yahoo.com ([66.163.187.147]:45673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bOy-0002XF-J7 for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 20:15:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837715; bh=Xt+mb6m7tWniSJtdAHfT+6sgDIYwsGqYiEmjWuTahH8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=Xwx+ouWAqVC5DgbzeE+huIPscCJcUdlhmJdPcEfnhHaTXPBooHNPzYK2cT/jD/wiophzN5pAEXHsC9FPDL926oIfiFg4+DyIXQwaZs2qRznXsXsNfM798mFEUVe8xPJDQ9XpGNI5AaRkjUexTYR5/kEO633OLX+NG96vP7hI/QF4DrkfFyKLPJ0n+i/4h3QX3ocaArv6SU+YJlpXsNWhYXO1EAKcWST3hgq/MzGRc8asR1DLoP5vHQbYHbjTFSsbyHv/q8E7SkBmUjSpu5FwqmfgKuRI0oNkRA0TLx4+UjWtXIkxoaibK2K9r5x3nYNkzNLNKVUhHtVYNKQkNUb/TQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837715; bh=Uye3aNcvY0T5l2HLT9TbOR6BEG+hRRiepC1n9coyP2T=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=bHiEFmdrbba69yzS5XOGCenxsUgJklH9uVdvpSO6uQivicqhuQHdxDih9bvKmtFvmb1TfY4ZTKgvdobJ/pUuJ8rUlZi1doeKpNPcqJk0v17MOJwW31rIVV2WDTluf2EM04d9XRVIiVsSybPuGlvee7coYwc0b2g89p7Td/GXtZYa99ZupF6s8n1CX6u6YJtmlhlwWO9SOYXt8KY5/WpXmXthBo12Gv313/Bi2j1yUbhj625XVB2X0JjSv352Lwt70QrMg5j8cOYJlYTSjufXqPtrSAYf/zL8JX5Pvd9V+D1CGvOPPEcBEfL/5eQKhLOnRQHIZtobVtLyTEnSLQ8nJQ== X-YMail-OSG: wjF5MBUVM1nM0JsCQzB4lN3RNrlubHOwnkV2B0uev68QN_fIUzuYbACcIW0hPAk vQU3mYIo9e10rkMaCYmM8ihAxoeNXu52k1t174C5hn1fFc1IOEOdNy98PMjwkY_Hjrx7ez1i7kHx KP5_bAGj0zkCMWC2Uesjh0yRKE0cPArrPaBaoaW0z0FeMjmd0wThSAUeQZWSn3Rs_5omNPYT5Z.G XNov.j2OwvMp0PhFkabDrLpo0gkC9OpFjxCZqruBTEt3_nSmKD3DtHjerXgWiRrxl4DA7OQfs5ou 4YzlZziABvJ4CRJPF20psBlgUP1v_KMFRq.SZRxYWexzIWi13mQ3AdNV8ScS5HoD626Dn1KekCFU iAQIfzPX5LkMs62_AUAULPfdcx.06mW7pzxcK3gOHWNVSPwYojTTMgtX9ULeiLZ4BIGDCNjTzMhS aqinFK7wbxntgKOX6Ytcvlnvf_d2O8tRVvS82eLOpHPII6v1_j.79bfmxViwUKo1GecRatwx6sRw YmGl7dSK.XfOM2uRUWC4zM0Atq8rtAS8OpxN0eiIPGshuB5HHBJgVMt8OHWrqbwcbLcsMYLI5XqI AUnwAMU3l1dPPOy3dZdEzEkrUkt5hlAYyoSDYcgJTDld4Q0rmznvl3DtMl8w0wi.ZQhQytdyDWIy qUrg26K9oQuSQYcR28sJ18yTokHJwoca7Ft.f9u9NQ5S_nW.v254mR4GzCaoynfBvQR4sp3Oqmt_ 1seNykgc6SZUlgN7zNgcb6qV38eWnH6QhDxqXrxXc3S9TxbfPlJVu.RLyNotZq4utW1qOs_ACvdh 6ZwKMkW.uFJJvn209FLaAnT01RgBlp3S6MNdn1yxYLLf0DMEZkCPFwXqxgToVhycEYiCsWb5tT02 3RoTv_rizqSl28ETsDbLMYxrLqhJBgdDH_3uE8Y4vQ4ajmllLs2GyTySdMlh9zFoZJsu13jjYGA0 6MBF2y9xcLGN3XT8mUbAXou9xijVcWo7reT.bsy3yf6axY4Oq_HKTdL28yPw.vl1HHBp0hbpYuOH E84kA80x61MV8fVbuHUnReopC7nOuiq4cLISF2K8DfcaYY0WPmQjad_lurdEjHwn8qwhl8SQrENJ hc7YX_rAXf7I7Fzufn6dWMunpkeToPoVfZ9sgGNLWBYa_ZEEcewVGY0C5hugW6kYDm6kzm2NIchY BQ4OquL6zqwtQ6vZ8wQ.mVjlFAgxjLy9ffQhpgXS9lgOTi.hcCvd6HBsXgImrb6j_YJRkCBqQxy0 rz2s6g.HC2BIXfZNzrHLlhCIWd6tUbOpSnLkrFxjVsNrg.bjbn5UgWOs96iQs_RtN15Rh_LRdSFc 8RxMfkcftkQG1dlLTyokttIPYFcj27YtZJDX5k9kdV8.t.3XoE9zTFdOpCIDsIgKlXBP.OJandR1 LTW1jj3TvimAQ50CxYVJog9cp7aDXOusbGWmSI0IpVxWGuhtOc15zed3f5j4AT5l6CFKvXQ1JGSE 37EHfq5C5Q1OaTGpYSbd4LZUKSeMgppTpsqqMa1KI7JDH3tj84jIxzQotTpXiaNQl4vtAuHF.Z5_ 4QKroc1ImtnrYhQSd3f9m9xrIyQhwFd92p._jmKrHQTm9TwuM0iNlx6_BtFtZY.O_7lpwWGxRdhD NdxF1sXREjASKf3Gai84mQEAv1GZfEaIk.E1Z.TVWXh0lDLELoz1xpU1BWHffZsrOssR.733qi6m npOWueS8RN7FVW.6zJSpCt5.hq9Wk.hhFW3Ih2ga8VV0XQjifsT_1ZrsRRZdH_5pcDp6olwSI_OM jTas0wgfxfj8fGmKXljlMXRdln5JmKo326akM630UlhPr8BzYfpE.k0WGXsk.rW3dg60E6cn1Dlh 6tyC3dw_5I0RaSnWzLF5TlZyFraB0JDUi7ZXb05t.DT1VhjO7y4fbJTLHlF8iyuD08oDJL0ckF5L e68dB2dlsg3ynFyGZxYDTc3gtGdlC_X.nkcPwAXAbdoLWFlEHzyuNhKQHyLxJxitsZ84q4l1kjAQ bsJs1b8MwM6ri8wjFrkTffi_PhJX7houREoN5I.EFo09L9v1fhgwCS0rCR.45uUo1aCzaIsnVcNk ngdBqufDXEdm1TidBiykcJXcxJKnNju13ayC5YiMaXUNXlvMevWBT4W5UHDGoKZF.V7Wfd_QilrC s339w6pd8ghkWEBL.l7sZd0MAEO82QigCWR5iD4RkkmfO.dMvjWS_4qXpQWTSMI3j3CRzSdMmaTT RYhRNzFYUf98vf8w2tiaWPZ.97ZpvjAMiq0XONpzu9FcPpdYv_NSWTGLS9eN6dNvBEQ-- X-Sonic-MF: X-Sonic-ID: def3c530-df46-478c-b9d5-5e2c2eae53ea Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 4 Jun 2023 00:15:15 +0000 Received: by hermes--production-sg3-748897c457-fqxqz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 90c06ad3d4977778f31103b839aae1fb; Sun, 04 Jun 2023 00:15:09 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 13:03:14 -0400") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <87leh0wm8h.fsf@igel.home> Date: Sun, 04 Jun 2023 08:15:03 +0800 Message-ID: <87bkhwm6bc.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 315 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Eli Zaretskii , Andreas Schwab , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > Other things which make Emacs busy still let Emacs respond to X > selection requests. Only if Emacs is still reading keyboard input. Responding to selection requests is only possible when it is safe to run Lisp. A cursory examination of xselect.el will show why. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 20:18:26 2023 Received: (at 63865) by debbugs.gnu.org; 4 Jun 2023 00:18:26 +0000 Received: from localhost ([127.0.0.1]:44527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bRy-0002cL-0v for submit@debbugs.gnu.org; Sat, 03 Jun 2023 20:18:26 -0400 Received: from sonic310-25.consmr.mail.ne1.yahoo.com ([66.163.186.206]:45844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5bRs-0002c5-7Z for 63865@debbugs.gnu.org; Sat, 03 Jun 2023 20:18:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837894; bh=o0AJhYk7WBQrzieB6Jijm00ufab5XBrVRwPvmKBv22g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=cn0WHAeZAnMKz4lj1DHcO1ubnDaE1+EI6dD2O7WWE5YwIVzMcl++e4c/MLofiQR63heL0dsWk6ge3qS4OqzgedHjm3AmSJqQyng0M3B8xtp2HjaCPBpuLU29uc90en9mfsTF/cK2+cq6zDXxjXC7mbxpivlehCKQc73uY+qKLVxdxhe9W2Gys+OuQXsJiV71ZiCsINbfpQlxXZb3+7eIBseBqnDnkmHLMip7YvF9r/dXdFZvplFrs4opdMfxJXe8ISyRHWbJ299PBP/Gelpe5W3ShXCgFBoV/VxqPepn3ZWGH95PHXGPl5PPucMDBam0uPnAXttiKFc9ix7Zw1zs4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685837894; bh=JXIpf0G1sT7vuIvafrIiW/OgaWY/ue/ihnR61C+FqKl=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=mju4U9jGw2FfQu6IDkDSuZkAwyzkrXyFtYTT6Hbn1AUEqcwJGKT8BfOVnKpWWbZrXe0r3XtgJoxqae86DqiKOWtinkoS7gjyU90OUSl2WodV5cQjfPj3t6TmJbaEmj6tBS6RRsB6S0v4kbZiih96V/cFcwLiHSqp2vAr2AC61mZsCmJyHFoKtqm7u2/5n20hkNxMUMRMcLhCPC8bXJaLANahAN7L2t5pa4HRyyfUA69Qw/hDQ20RjALKbU9VWxCA/eVrl5sSMHiY/kMhaWM0xzgek+r7HezIAwvESFdw9k4xaw1AhJILlOhHCuRZ9n25tloD7NkmT3zZYM/DUEMcpg== X-YMail-OSG: epiHTpAVM1kGngEW30iYDN_vB2qIJdEou1RAdhM0ODAcHOAF8TcToT0oM89T6v8 vx2jFiBB9jsbWix8Mk.Ps6LhdO2rL3kPhjLmBwXLU5cpCmM5hsxhN8JxuxsejEUesVYGo3hrJxjU nvJ4TJavUnGLX5qkRD5gDn_gILydy7140IIAw63Ez9LifPX9oazUfqDl5hHQSmcS4eonF1E0I96A n.3Kb2ZwKLBNLIPACODjVKjZvbwUiseJGEoiiE4K7G_f66bPDZeXL1RJhVUCqYdIXyRCdg9VW078 stZSgvJ3j8l86pJlvwZSlNpMqV0BnG6fGttVodoI1RW0uDFRjxjol_qToVyqAgEzbSO7vVI3SNxS vRnT8GmkXyshm_DdsonRdM4ZAZ53BKwp5WOev3_C7wOtSeGfF0lFXUcMud3W_hl4RRy.6SgWKp2Y kMkepBD1.Qx22NvZx6W3Y.LjlDOOGrfh48kFFaNqULJzlEfj4th80jb.a45FpzE2p_CqjHquh809 D8KLSO8wEhvCp3NSEZZygZQXFPXyXmKMXZDZ5L_sIcZrC5Tf_X0LQEqUiRFzDrv1Qk6E6Y_jy1jA X.2tX_wOUbpK8iLxIBGOdq1CSLaFw_8u67SFgbKNxM1waqhkuvb55YuthoPzUWyABMITxa4CC4wJ ZRxF9aR1eMCmmEUZ4DSMBS4GYR_uKUnvhafHWFpzfd191pALrmvOQL7kMWitg5mUtPo4bd5Ya_HJ C5kTCSXH2msXhpqsszRb2Mb_amFrHoDxte_a6atx3Fy5wrO.Rsa1Q7NLII1Ho7gTORBP7d0C6x56 6G3hjfuHtkrcHTTNdaGuoJIM1j1.i0WzD2ePfP7zhtNUqs006t8TME0AjufxEw.2Z2W80Iq7rnyE CXP5KkRMDdgwmE_NcTYK_UFGtfEiGe5dU_muL1p3ed31va1QnrfGx8o6ouSjE0Lf0QrqHm81q9ud Xzw5_.9UaIo3EpXKltnKOgmo0CJHE5lnqLFppUe0SDCQhfhBrdA36DFo9pCuVjIfyBCtaFi3mS2g 0yRq7g1KW7QRcymBPg2YnrU95CLgAoR_lWzR3txY0toWtDhP5fm4WENvYY9TN64gpz3EXSyVgJZZ Y3rf0gdeBLmxKC_0Trc4IZtpDzGJJunN4Ui1Y1yxDEiuCRgx6fIXCVfpeBRDuNrHcU0h8H7YQTQ1 iAXILdDljle1A3fNzdAeUm6YKpKzfVUnpJ28Ojf5h3hAbMaNmm0gN1c1GfqzKFomSDov.a8DKb6d maMp8pcDA79D8UFlS9k4DZxjx5coa1JGHQvWtemhp10r4ei1FP6JxGB1dQkD4AoKLhAwXLD6RNog ABCfjcNQa2mynO9VxP9oYXrOAQp8YoC0Lb1WUWtx4LMH4jHKxKufumv__PmZCBFUoQEBhIa3FTac JHGfeRlRTdg31ulCImmrFzuiQP.8aqW7ROiNAwDw6dLneZerN4muD1I51my8W4NMKDnWEiw3lHd8 YSDwpXpjyGJeE_wwgYoAjeYEOYhojcZFgfwjeNl6HuR59Z3fRBD9ovuD1qg.ctXJJsYAtGQabtZq HCPcgObG19myJkIAPaHvJt_wdhcSfKDq1Xurnvv3Cfgn4SCfB7FRKS7Uz67h2SAUosWSnKmAIyNk Pgwbtm3envxdRmp8HI6H9Vs8CSdhl4uoIvIiqeEjUxA5MGPHpe7U9T9zXb1gWWy59hll3yTMuPtj s.XYNOEPp6WsJDn6r5SAV.4ysqDHdDlF6raIAlKcbDX4T1g98RsfPPM0jltKLJQMonDNWAkjuMfq zt4uJa6c8W7DMRqXZ9LhTAWoxqnc45l3gk2GCBw3pDg0l5KGiMaDIhzghwO9hBc3Ur2EbuEKZL4h UmOIRqKrT6dqlBOuzLqcmsaOot5NqNkBiAZTMLH.KPoNhNRwI_oMmHAI9a68f_LnRXAzLhHtKRjS PeZQHrBNbf0cArbg6z7vggOyp3mHm0XZIVVZ.y2hjzaQDCb1yL4aapV19Yp.VgQNFVOmk9D5sXvB u11l9Z9Fuy8gS0tX.X5Qunpcu_7Bmul._Xx5Z1W4hr0royN1emtKFatEmG08QAecLsBqE_2hmjDx ahtyxKK8hl_EgllH61t2wy2E3xn1QjbPne6T6ZFsM4PpoHj6fOePNqVgTh3nqWsFImYaTXkULUzx qx7s26ZpRuzIVIc_2jVXWPbPnUNxBIvTO6OpP13RO6dLRAex7Fy0Qo5savNE3yJVgLD0fEJBXwIY m_ncFBVCV4uprJh9aHWmQBFue1JAvAxnopuZZ.g5BFsqtxFPOr0WzvuggeO9HKjqO87cAtg-- X-Sonic-MF: X-Sonic-ID: 85063411-317b-4c9d-afc5-728edbca1c46 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Sun, 4 Jun 2023 00:18:14 +0000 Received: by hermes--production-sg3-748897c457-h9s95 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 549e7d3016c2ec422fc35b588f26e33c; Sun, 04 Jun 2023 00:18:08 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: <83a5xg8vzo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 17:24:11 +0300") References: <83edmt9j8i.fsf@gnu.org> <87bkhxnhpk.fsf@yahoo.com> <87wn0kn3zu.fsf@yahoo.com> <83mt1g9044.fsf@gnu.org> <83leh08xmn.fsf@gnu.org> <83a5xg8vzo.fsf@gnu.org> Date: Sun, 04 Jun 2023 08:18:02 +0800 Message-ID: <877cskm66d.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21495 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 482 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63865 Cc: Spencer Baugh , 63865@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > AFAIU, the only "everything" that is blocked is an application that > happens to request an X selection at that precise time. That should > be rare for short enough call-process runs, since the same user is > doing that. Btw, it seems only fair to mention that hangs here are clearly the fault of the program that hangs. All reasonably implemented X clients implement a time-out mechanism and listen for the selection owner being deleted. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 23 10:27:09 2023 Received: (at 63865) by debbugs.gnu.org; 23 Jun 2023 14:27:09 +0000 Received: from localhost ([127.0.0.1]:39311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qChkg-00006P-63 for submit@debbugs.gnu.org; Fri, 23 Jun 2023 10:27:09 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qChkZ-00005p-J4 for 63865@debbugs.gnu.org; Fri, 23 Jun 2023 10:27:04 -0400 From: Spencer Baugh To: 63865@debbugs.gnu.org Subject: Re: bug#63865: 29.0.90; call-process while owning the X selection hangs other processes In-Reply-To: (Spencer Baugh's message of "Fri, 02 Jun 2023 21:55:09 -0400") References: Date: Fri, 23 Jun 2023 10:26:53 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63865 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) BTW, the buggy behavior in Slack at least can be fixed by running: slack 'slack://setting/?update={"isClipboardReadDisabled":true}' then Slack won't constantly try to read the clipboard in the background. (Apparently this may be fixed in the future, future readers should check with Slack) Though, I'm still of the opinion that we should make a call-process-with-lisp which doesn't stop Lisp from running while call-process-with-lisp is running, and use that everywhere. Then we wouldn't be triggering such bugs...