From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Newsgroups: gmane.emacs.bugs Subject: bug#44007: 26.3; Strange shell mode performance Date: Mon, 06 Nov 2023 16:00:00 +0100 Message-ID: <87v8aeyl9v.fsf@gmail.com> References: <499ab53f-7c23-b5ed-6105-3072fffb4bfe@gmail.com> <83imbby3yt.fsf@gnu.org> <1cfcee64-0002-dedd-fb8f-528660e7c807@gmail.com> <83v8af2iey.fsf@gnu.org> <87bkc73uk4.fsf@gmail.com> <83jzqv2ezv.fsf@gnu.org> <87zfzrx8hy.fsf@gmail.com> <83h6lz2bei.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8922"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44007@debbugs.gnu.org, Herman =?UTF-8?Q?G=C3=A9za?= To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 06 16:06:43 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 1r01Bb-00024D-DM for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Nov 2023 16:06:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r01BL-0007nN-3a; Mon, 06 Nov 2023 10:06:27 -0500 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 1r01BJ-0007mO-II for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 10:06:25 -0500 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 1r01BI-0007Un-LT for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 10:06:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r01Bt-0007b5-M1 for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 10:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 15:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44007 X-GNU-PR-Package: emacs Original-Received: via spool by 44007-submit@debbugs.gnu.org id=B44007.169928319629173 (code B ref 44007); Mon, 06 Nov 2023 15:07:01 +0000 Original-Received: (at 44007) by debbugs.gnu.org; 6 Nov 2023 15:06:36 +0000 Original-Received: from localhost ([127.0.0.1]:40377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r01BU-0007aS-Ce for submit@debbugs.gnu.org; Mon, 06 Nov 2023 10:06:36 -0500 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:54403) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r01BS-0007aE-Ju for 44007@debbugs.gnu.org; Mon, 06 Nov 2023 10:06:35 -0500 Original-Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-53e04b17132so7559867a12.0 for <44007@debbugs.gnu.org>; Mon, 06 Nov 2023 07:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699283151; x=1699887951; darn=debbugs.gnu.org; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:from:to:cc:subject:date:message-id:reply-to; bh=emLpmSj3W9f6EehiR/4faJdm2+sAP1tL527OaED69VE=; b=BRs2d8+by6fV3C6/kbag3Au2Szu94/pWIfSX607tAxS9wywo8SLHiI++nqnVJbq9Rw hW6HtiRgmfe5Jw9DN/nSsGqH3bdZJwWHZ3AdiHEtaSX6buWhd+dcUn6zfeiPJyKq6Mh7 ATFdfND8u+QfUKY4zsqYaqj48pTe50HVpcq87JiLpQ3/mVTIGYeOWr3lcoUvSb/T1W9/ aLd0GqB5hlSOAMjBsvGsmMxkgXj+YA5VxOHAcxxFGPCnPpITj9QfPJ9YXoNlCliKgYzR z+DOXPqfVH8xDINakbiqzKD7wDD2tIiT+onXsd0VTu+PmNosdgqVAoyCWb2idligztwk vsjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699283151; x=1699887951; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=emLpmSj3W9f6EehiR/4faJdm2+sAP1tL527OaED69VE=; b=E5egeQ8F5/knkjI4+1wbYpiRRWEjbQov2A/8eapHQoDMsznhU9niqKytmR40c6idGT +ZdYvMKk8NBlOJC97Kz7aq0TiSE106Z9Bm0JqxrtZi7OkUR7MQmuKTUXREfVRzXXNF28 7DSYc0hbaDN0+lg1DYbkmSbtqe5EWOCNAFQTAOMKa10Zhn0KzyRQuFtlnN6A/8YDZk2X Hy6YDPgW3SabbhIPmKA/bygShMm7PaK5Oa6Lx8odnegZqFHSRm0JzpzckoEHibL1vih6 3MYvCUp0r40x74WejFZ2GgJBQCf0es3l9N7SFG3ZOa9jfEROHQnS5lQKcki1kp9Twq/T fNfA== X-Gm-Message-State: AOJu0YzRoTNEgQom6Tuh0NkK6l2832mcjtzzwvHeXHdAulnflhD0eeRA JEv0K6MyJKP8Kgk5lBV7rNE= X-Google-Smtp-Source: AGHT+IGMZKBuRbd5PHHPC34ANMxGd/wIBpMpDvSBY4l+KPlSfPsgfTwHWqMqX9LM2Y2rxFsCsKfyfA== X-Received: by 2002:a17:907:7e84:b0:9dd:cc3d:7ba7 with SMTP id qb4-20020a1709077e8400b009ddcc3d7ba7mr6525412ejc.29.1699283151185; Mon, 06 Nov 2023 07:05:51 -0800 (PST) Original-Received: from localhost (62-77-231-86.static.invitel.hu. [62.77.231.86]) by smtp.gmail.com with ESMTPSA id t18-20020a1709063e5200b00997cce73cc7sm4229282eji.29.2023.11.06.07.05.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 07:05:50 -0800 (PST) In-reply-to: <83h6lz2bei.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273875 Archived-At: Eli Zaretskii writes: > I believe reading again immediately could make Emacs > unresponsive for > prolonged periods of time. We are talking about reading > sub-process > output asynchronously, which means we must not read in a tight > loop, > because that would have the same effect as calling a subprocess > synchronously and waiting for it to finish. > > Even in this particular scenario, the user should be able to > switch to > another buffer and issue commands, while Emacs is reading from > the > shell or some program invoked from the shell. I thought that the fd is nonblocking here. But even if it's not, how does Emacs determine nbyte parameter? Because I suppose it should be at most as large as the available data in the fd. If not, then emacs_intr_read already has the chance of blocking anyway without the loop. Also, I have the loop in place for years, and didn't notice any problems.