From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#65211: 30.0.50; threads and accept-process-output Date: Thu, 10 Aug 2023 17:21:28 +0200 Message-ID: <87sf8q6hzb.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10496"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65211@debbugs.gnu.org To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 10 17:22:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qU7US-0002ZM-D6 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Aug 2023 17:22:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qU7UC-0008JY-LI; Thu, 10 Aug 2023 11:22:04 -0400 Original-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 1qU7UA-0008JB-LW for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 11:22:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qU7UA-0008UB-DW for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 11:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qU7UA-0007rw-8f for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 11:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Aug 2023 15:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65211 X-GNU-PR-Package: emacs Original-Received: via spool by 65211-submit@debbugs.gnu.org id=B65211.169168090530207 (code B ref 65211); Thu, 10 Aug 2023 15:22:02 +0000 Original-Received: (at 65211) by debbugs.gnu.org; 10 Aug 2023 15:21:45 +0000 Original-Received: from localhost ([127.0.0.1]:43843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU7Tr-0007r7-HN for submit@debbugs.gnu.org; Thu, 10 Aug 2023 11:21:44 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:61706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU7Tl-0007qp-6h for 65211@debbugs.gnu.org; Thu, 10 Aug 2023 11:21:42 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-3fe82a7864bso1341525e9.3 for <65211@debbugs.gnu.org>; Thu, 10 Aug 2023 08:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691680891; x=1692285691; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=K+YHQxPFLms+Vt0s/3XLF5z6vOaBx19fmcxSu+0u+dQ=; b=jJQ12GKXp0Yau+bJ4st07SfVE0HjkYwOiihyas4UoT7V2GpB5Z+Do7SEBOdtqCX9cA 1F8UbmPWyYAQk7pMCM2w6xRgcGT9/EcnJ4MwHL2R14euKGihxfEBzvNLLgRhVNrwiPL2 yK6L6mNx0krBslhaUPgfFtMwyu/ESMQ1aeK54x/KrhylUZs3/a7F6+HT0Ug3VMK5wiZz XFRZYHrO2uOTe5HdhsKIly+B1qxNIC+tz8J0AUBCa166TOQ/0q+ru0domrTVE33w0dCN B5h0JnDVAS2hT0VqFc6x8nGfecmwk9SEjvRPczDYVvFUW5GdNLqY47SoOw0KjEVa+J4G GcYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691680891; x=1692285691; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K+YHQxPFLms+Vt0s/3XLF5z6vOaBx19fmcxSu+0u+dQ=; b=JjLxE7DzhzQctHBoyq46tQTkp4NYa5JrUf2mVE1k3fUhgq+uhbVQhKxu64YP29Hu8v DInGSWvdxQ1rQ50BRo6K4VO7qAQgfsCRHd3BO9YRmIqyzCFof1sCpU6/ToiM2aIkkS1Z hyCDV215f0Hkbk1d904AkzVXXTS4t3FY+SUeyPB427hpkn19FbHYQRR85C0Dv+M/5Yew AzsDuVu8x1xDWvk7x7eb3iWBFFW1KyxnZ90H42CZg4/8tNVNWa+cGaXO5hn/SE2i7sZM lWWgHZ4/CtYFUxzpQivnX6G7muCtUCk1o2YHB++hwqdTpAGhsLB90gYblD8EOkKUZ0pw 6wNQ== X-Gm-Message-State: AOJu0Yw5tS4JzXRBZipnrdnQ8DFByBgdjVlSutTmOsNdLvmtAY0M9za6 94/i5MLNLGpfxfVYY4MNqk6nWGr4x2E= X-Google-Smtp-Source: AGHT+IEWYcCuju+pnXCY6C90Q4Xtd0qpUzAGFY0I8NXKdu1sVi2AYnmaGUSkWEKxb0QOkK80RKCKlw== X-Received: by 2002:a7b:c5d4:0:b0:3f9:b244:c294 with SMTP id n20-20020a7bc5d4000000b003f9b244c294mr2468551wmk.35.1691680890615; Thu, 10 Aug 2023 08:21:30 -0700 (PDT) Original-Received: from rltb ([2a01:e0a:3f3:fb50:b086:92d7:f1ed:48e0]) by smtp.gmail.com with ESMTPSA id p4-20020a1c7404000000b003fe1a092925sm2422649wmc.19.2023.08.10.08.21.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Aug 2023 08:21:29 -0700 (PDT) In-Reply-To: (Helmut Eller's message of "Thu, 10 Aug 2023 17:04:48 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267143 Archived-At: >>>>> On Thu, 10 Aug 2023 17:04:48 +0200, Helmut Eller said: Helmut> The test case from below hangs when executed with Helmut> emacs -Q --batch -l apo-tests.el -f ert-run-tests-batch-and-e= xit Helmut> It's not 100% reproducible, but it seems to hang 80% of the tim= e. Helmut> The test is fairly complicated and involves a TLS connection, a Helmut> sub-process and a background thread. The background thread sta= rts a Helmut> sub-process and reads all its output until the process terminat= es. Then Helmut> the main thread opens a TLS connection, sends a HTTP request an= d tries Helmut> to read the response. At this point, accept-process-output han= gs even Helmut> though there is output available. Helmut> I think the reason for this problem is that the sub-process use= s a file Helmut> descriptor (usually number 6) and sets Helmut> fd_callback_info[6].waiting_thread to the background thread (in Helmut> compute_non_keyboard_wait_mask) . Later, the TLS connection re= ceives a Helmut> file descriptor with the same number (6) because the sub-proces= s closed Helmut> it already. That would be fine, however Helmut> fd_callback_info[6].waiting_thread is still set to the backgrou= nd Helmut> thread. So this time compute_non_keyboard_wait_mask doesn't in= clude 6 Helmut> in the wait mask. Because 6 is not in the wait mask, Helmut> emacs_gnutls_record_check_pending will not be called and Emacs = doesn't Helmut> notice the buffered output. Helmut> The intention in the code seems to be that clear_waiting_thread= _info Helmut> resets fd_callback_info[6].waiting_thread to NULL, however by t= he time Helmut> that clear_waiting_thread_info is called, max_desc was reduced = to 4, Helmut> because somebody closed file descriptors 5 and 6. So Helmut> clear_waiting_thread_info doesn't touch fd_callback_info[6]. Helmut> A possible solution would be to reset the .waiting_thread field= in Helmut> delete_read_fd, like so: Helmut> diff --git a/src/process.c b/src/process.c Helmut> index 08cb810ec13..74d0bf252ab 100644 Helmut> --- a/src/process.c Helmut> +++ b/src/process.c Helmut> @@ -513,6 +513,9 @@ delete_read_fd (int fd) Helmut> { Helmut> fd_callback_info[fd].func =3D 0; Helmut> fd_callback_info[fd].data =3D 0; Helmut> + Helmut> + if (fd_callback_info[fd].waiting_thread =3D=3D current_t= hread) Helmut> + fd_callback_info[fd].waiting_thread =3D NULL; Helmut> } Helmut> } Hmm. Maybe putting it in `deactivate_process' is better (not that I=CA=BCve tested =F0=9F=98=BA) Robert --=20