From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.bugs Subject: bug#65211: 30.0.50; threads and accept-process-output Date: Fri, 11 Aug 2023 10:32:53 +0200 Message-ID: References: <87sf8q6hzb.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10350"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65211@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 11 10:34:25 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 1qUNbF-0002Zr-2u for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Aug 2023 10:34:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUNav-0003lo-9Y; Fri, 11 Aug 2023 04:34:05 -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 1qUNat-0003lO-6R for bug-gnu-emacs@gnu.org; Fri, 11 Aug 2023 04:34:03 -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 1qUNas-0000Ct-DV for bug-gnu-emacs@gnu.org; Fri, 11 Aug 2023 04:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qUNas-0002Tm-9a for bug-gnu-emacs@gnu.org; Fri, 11 Aug 2023 04:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Aug 2023 08:34: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.16917427849445 (code B ref 65211); Fri, 11 Aug 2023 08:34:02 +0000 Original-Received: (at 65211) by debbugs.gnu.org; 11 Aug 2023 08:33:04 +0000 Original-Received: from localhost ([127.0.0.1]:44858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUNZv-0002SG-Ie for submit@debbugs.gnu.org; Fri, 11 Aug 2023 04:33:04 -0400 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:56439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUNZt-0002Rl-Hq for 65211@debbugs.gnu.org; Fri, 11 Aug 2023 04:33:02 -0400 Original-Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2b9a2033978so26718421fa.0 for <65211@debbugs.gnu.org>; Fri, 11 Aug 2023 01:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691742775; x=1692347575; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=RRRTt6p2pi6raXPk1D3iPMwvaZhTCklLK5kXqf8DYtI=; b=kMrEEHB7qseVm2+31Xrjsi1hoO3tX8Pxb+e20nSRVThiywM3rppVS+GKe97dRoqNYW Lb/EMUqWlxcPBHB5S5v3NABRUelY1daOBASEVeQ7XULrisifYzOM3ZH5tvSZALi4sIDb O/RL689qTvp+qySSeEgAcfhAEMP5iR+YFqw0i+bG+DSpjgTZS6dw7cLUdUnQdLxVURPt 4VgBLDn07yqqhsZM03zysT7KcexpSP1JU/pbyllb2TbuoGT3a58V2zqwlrnPj+Vr5I+4 BHx1TI+xhAE2ucBMI6/BizgCH0ZBfJZSDd54/gJACI5EpJpWtlj/j7vSKVt7WU8+voC6 qvcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691742775; x=1692347575; h=mime-version:user-agent: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=RRRTt6p2pi6raXPk1D3iPMwvaZhTCklLK5kXqf8DYtI=; b=FzC5acn0z8Ewm+NOJT5YndWDN5xog/8yvFShUBBhAFqFl4w8jfJj36UeNlGQVd80dg hO9GqFNsm8lVRUWSF8LQYFk1GYIuGR6v3c84f89Ka+V52ojzbGv3Q11BMuGT2e8tioS+ I2ZRKuKFCltXanFTWxPPq3kHHHpAHddslVxqgWcXgeNBnC48cXbN+CxGiz568x5cH5lZ AIQEwXPoH6jmRqkdjSFkShwA9FKBZMIYxwd6htdSPNN+Cx40rJW3Z59tzQGPiHqpI6cU WT97hJtYVssPhtaywPJ8M2B3/ZT3kveVbYLvwRFd8Bgtz5EosESYOb3XatlXFebrDZNu 0CBw== X-Gm-Message-State: AOJu0YwunQMTC+V0Z4tAb/yiUISIh8AchVU5YK9hwmjUjjBvJR4/qzjd NmS4+kdd6XJLqU+7dWRh8+eLTgwEMvw= X-Google-Smtp-Source: AGHT+IEzDeCSW8MUsCHnWncqqYqVNSAVcuv8jUv2GyfiU4HsM9BdHZugQakxu92BHJ+EBjU1cadFGg== X-Received: by 2002:a2e:b616:0:b0:2b6:ea3b:f082 with SMTP id r22-20020a2eb616000000b002b6ea3bf082mr1041416ljn.38.1691742774701; Fri, 11 Aug 2023 01:32:54 -0700 (PDT) Original-Received: from caladan ([185.127.213.71]) by smtp.gmail.com with ESMTPSA id x16-20020a05600c2a5000b003fe13c3ece7sm7387488wme.10.2023.08.11.01.32.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Aug 2023 01:32:54 -0700 (PDT) In-Reply-To: <87sf8q6hzb.fsf@gmail.com> (Robert Pluim's message of "Thu, 10 Aug 2023 17:21:28 +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:267199 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 10 2023, Robert Pluim wrote: > Hmm. Maybe putting it in `deactivate_process' is better (not that I=CA=BC= ve > tested =F0=9F=98=BA) After a night of sleep, it occurred to me that this could also be considered a problem of incomplete initialization of the fd_callback_info[fd] struct. So I wondered who is supposed to initialize it. Unfortunately, there is half a dozen of add__fd functions that set various bits, some call each other, some duplicate code. None of them sets the waiting_thread slot. And there is no single point that clears everything out (except init_process_emacs). I also discovered that recompute_max_desc considers an fd unused if the .flags field is zero. Luckily, recompute_max_desc is only called in three places: delete_write_fd, delete_keyboard_wait_descriptor and deactivate_process. The call in deactivate_process seems redundant as it calls the other two anyway. It seems easier to re-initialize the struct when it becomes unused than to initialize it when it is used the first time. So I'm proposing the patch below that moves the re-initialization to one single place, namely: recompute_max_desc. Helmut --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Re-initialize-fd_callback_data-fd-more-thoroughly.patch >From 675a76b297e9f050f719489a1419f0278ad8e9ae Mon Sep 17 00:00:00 2001 From: Helmut Eller Date: Fri, 11 Aug 2023 10:31:24 +0200 Subject: [PATCH] Re-initialize fd_callback_data[fd] more thoroughly The waiting_thread field was not re-initialized properly when a a closed file descriptor resued by another process. (bug#65211) As recompute_max_desc must be called when a file descriptor becomes unused, we can do some re-initialization there. * src/process.c (recompute_max_desc): Take the fd that was just deleted as argument fd. If the flags field is 0, reset the rest of the struct too. (delete_write_fd, delete_keyboard_wait_descriptor): Update callers accordingly. (delete_read_fd): This is now just an alias for delete_keyboard_wait_descriptor. (deactivate_process): Remove the call to recompute_max_desc, as delete_read_fd is called anyway. --- src/process.c | 46 ++++++++++++++++------------------------------ 1 file changed, 16 insertions(+), 30 deletions(-) diff --git a/src/process.c b/src/process.c index 08cb810ec13..cd5fd97e9d6 100644 --- a/src/process.c +++ b/src/process.c @@ -507,13 +507,6 @@ void delete_read_fd (int fd) { delete_keyboard_wait_descriptor (fd); - - eassert (0 <= fd && fd < FD_SETSIZE); - if (fd_callback_info[fd].flags == 0) - { - fd_callback_info[fd].func = 0; - fd_callback_info[fd].data = 0; - } } /* Add a file descriptor FD to be monitored for when write is possible. @@ -544,19 +537,22 @@ add_non_blocking_write_fd (int fd) } static void -recompute_max_desc (void) +recompute_max_desc (int fd) { - int fd; - + eassert (0 <= fd && fd < FD_SETSIZE); eassert (max_desc < FD_SETSIZE); - for (fd = max_desc; fd >= 0; --fd) - { + + if (fd_callback_info[fd].flags == 0) + fd_callback_info[fd] = (struct fd_callback_data){ 0 }; + + if (fd == max_desc) + for (; fd >= 0; --fd) if (fd_callback_info[fd].flags != 0) - { - max_desc = fd; - break; - } - } + { + max_desc = fd; + break; + } + eassert (max_desc < FD_SETSIZE); } @@ -569,17 +565,10 @@ delete_write_fd (int fd) if ((fd_callback_info[fd].flags & NON_BLOCKING_CONNECT_FD) != 0) { if (--num_pending_connects < 0) - emacs_abort (); + emacs_abort (); } fd_callback_info[fd].flags &= ~(FOR_WRITE | NON_BLOCKING_CONNECT_FD); - if (fd_callback_info[fd].flags == 0) - { - fd_callback_info[fd].func = 0; - fd_callback_info[fd].data = 0; - - if (fd == max_desc) - recompute_max_desc (); - } + recompute_max_desc (fd); } static void @@ -4809,8 +4798,6 @@ deactivate_process (Lisp_Object proc) delete_read_fd (inchannel); if ((fd_callback_info[inchannel].flags & NON_BLOCKING_CONNECT_FD) != 0) delete_write_fd (inchannel); - if (inchannel == max_desc) - recompute_max_desc (); } } @@ -8134,8 +8121,7 @@ delete_keyboard_wait_descriptor (int desc) fd_callback_info[desc].flags &= ~(FOR_READ | KEYBOARD_FD | PROCESS_FD); - if (desc == max_desc) - recompute_max_desc (); + recompute_max_desc (desc); #endif } -- 2.39.2 --=-=-=--