From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.bugs Subject: bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly Date: Tue, 16 Nov 2021 18:06:51 -0500 Message-ID: <92d3e509-be73-88c8-0085-f13c3716dd1b@cornell.edu> References: <874kbtfthj.fsf@gnus.org> <835yw9cwoa.fsf@gnu.org> <87mtpla013.fsf@gnus.org> <83zgtlbaw6.fsf@gnu.org> <87fsvcuttw.fsf@gnus.org> <83czn12uz1.fsf@gnu.org> <837dd80zc7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25046"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Cc: larsi@gnus.org, 50043@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 17 00:08:16 2021 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 1mn7Yl-0006LO-Np for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Nov 2021 00:08:16 +0100 Original-Received: from localhost ([::1]:53064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mn7Yj-0005pR-HX for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Nov 2021 18:08:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mn7YZ-0005p3-N2 for bug-gnu-emacs@gnu.org; Tue, 16 Nov 2021 18:08:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47875) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mn7YX-0005Xk-UT for bug-gnu-emacs@gnu.org; Tue, 16 Nov 2021 18:08:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mn7YX-0004do-Q5 for bug-gnu-emacs@gnu.org; Tue, 16 Nov 2021 18:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Nov 2021 23:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50043 X-GNU-PR-Package: emacs Original-Received: via spool by 50043-submit@debbugs.gnu.org id=B50043.163710402217695 (code B ref 50043); Tue, 16 Nov 2021 23:08:01 +0000 Original-Received: (at 50043) by debbugs.gnu.org; 16 Nov 2021 23:07:02 +0000 Original-Received: from localhost ([127.0.0.1]:59419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mn7Xa-0004bB-0J for submit@debbugs.gnu.org; Tue, 16 Nov 2021 18:07:02 -0500 Original-Received: from mail-mw2nam12on2122.outbound.protection.outlook.com ([40.107.244.122]:22240 helo=NAM12-MW2-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mn7XY-0004ag-FX for 50043@debbugs.gnu.org; Tue, 16 Nov 2021 18:07:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WGBBpKD7E0Az2NDGHYhzFse8AAMCH8plHHPdH4llm0dtimiUknL/UwO029x+sbzQEC/8/Lcy/y0LW3IiZOBEk9+IWsrveZisMk62R+04tjm3UHcUtNoaGAUy91Q1RnT/KUQ5/7So+xZhJwTZ37FH1T/IKPfTMCqRADhrtVw3s3u8UQIDO6wkULwlM10gf5c745TkbMVkU+ufoZWg7mzm1kEDhGwSn+1BNTR3OhZo8pSqpOm8IMkmIAZFFM8rDfjdFsCUffyoYh1Uphq2KHGfJuwtE3dU7Su2JLjxCovWQlVOHKn9CRo2Q8nWmpBi2P66wfBBhNNiRq+xx9cp6/og6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O1mPdMi8eGDjDGxIXE8WsEOmEMmI6uTIo5MrOIz6Yys=; b=kT2iUe8fltt4pUH8A3w8oFFzIsa/MkZC34F3wYn7XbW+qpFSS6q3+LQ+MEnWNCzoGxfxMbYKZ+vB8tNUvox3M2vFcVN6qDOim2tL8zrl48YwVCogWLjPu7e3Xu4YMLihP3CupB4T0EOAVonmt9YkPSR6FJpIK8K7Y3cdhUrt0b5NaXlXRmbkPFxJAI3pM9li4JhCb9IpT80D9stcZjNGoWlIn9Mn3vq7Fiu+/PmR84kMbI6mDd3WiEW0f3u5Zh3qrapLhRyhhV1CO3qgD/LKjft1encqKTMF11auSEWN/2m2WpXTo5QurexiVuiDCBT92F3uYy0ZGBBJ1XrDaETOVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O1mPdMi8eGDjDGxIXE8WsEOmEMmI6uTIo5MrOIz6Yys=; b=NPRcl8M0ZO2EZBZsdodbRaKjgCC9IjdiRR8BGYWsm/tNRluTlJ0/qa5K4O1o7t5K2wXldegph0ecZdVdqbjCJ5MsahG8RzNHFl89ZucANYjN87Khse0nr6+/9SI0HlyvESmJQTdK/eLli7H+YVna2JeUGworhl6sc/ugWH7rb/4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cornell.edu; Original-Received: from BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) by BN8PR04MB5473.namprd04.prod.outlook.com (2603:10b6:408:5e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Tue, 16 Nov 2021 23:06:53 +0000 Original-Received: from BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::88c4:79c5:1eb1:b969]) by BN7PR04MB4388.namprd04.prod.outlook.com ([fe80::88c4:79c5:1eb1:b969%7]) with mapi id 15.20.4690.027; Tue, 16 Nov 2021 23:06:53 +0000 Content-Language: en-US In-Reply-To: <837dd80zc7.fsf@gnu.org> X-ClientProxiedBy: MN2PR06CA0017.namprd06.prod.outlook.com (2603:10b6:208:23d::22) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) Original-Received: from [IPV6:2603:7081:7e3f:3419:1c5d:e1a9:7b:59ab] (2603:7081:7e3f:3419:1c5d:e1a9:7b:59ab) by MN2PR06CA0017.namprd06.prod.outlook.com (2603:10b6:208:23d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19 via Frontend Transport; Tue, 16 Nov 2021 23:06:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3fcb34d5-6da4-43d1-b7f8-08d9a955c70f X-MS-TrafficTypeDiagnostic: BN8PR04MB5473: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XEtpK7cvLR+XMbjd2JoolnP8xVSFnpdlpdUNs6MjpPT8kGqJP/FbnDy89NXGc0a5KbD1vN2k/DTOq5QmYNY+3iZWsRTolVImdr3pPJ5hkfB6nqnPqJbW9Rz/uDnl/ICl8fNUvzf6hulCcOas6Q4nvmLQ70WD5T8F2yAmqJq52w+Z8ToxA0AbsL9MQg3lMOVOC/+Ln6Loh8heyBipX16tkNHmiM13YDgffIJgqyRlfv2PiEV+itDFxkb6efGHHNjxg5LA7WFFYsw30scY1hq3y08mVpsA//tHUeNgQ8cDk//3fQLg/ds3vQSY3JK+4C6gjIVQ6xvASRO/z24Z65t5lRWZjMSIukTGL6DdQS2ajzseR3juU0gCj78EX+nROChf/vHZWdFTdm087cYcZ0vWypGT1vVc17snamFPBm/1HO75NawElQ3YS5mjHxCoU8xPE35Aazonjbtn8sXfrZDRzMva3gGHNzskNUl8vQVHRajKhuWAEEbtFwngDOKZk0EhxgSGY0rMPGIRsDqpuZ+8hx3MVqCtxESzuj/waVMw/3RJdXvfNozsG55NK5Xy744GN4ZnlFQ+tJNSqxaNP5gSg5PqTsA9TIBkcvKj7i5P+YbQvR82veidNjwFIKqk6XAD7Wp2DpjSMkEuO+QcFsNayaQaIQAiBq3kNXsfU8RZyNTikIe3pSouvARK3eSYZBasMnJF9ynpozF99lOSExBrvCAGCP3IuARgrIw3LgZZl34= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR04MB4388.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(31696002)(53546011)(2906002)(75432002)(6916009)(83380400001)(86362001)(8676002)(38100700002)(31686004)(5660300002)(8936002)(316002)(786003)(2616005)(66556008)(4326008)(6486002)(508600001)(66946007)(36756003)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 7+aaAj4GcvVRJt0yR/sZ4TuEfzgbOnxbE0qmhyGpRzc4MI2tGKMgm5aZ2jHzfR86EXd/BgsxQgUQIr9GLOGgayRXODx4893pIeLgCsG6Q6ltaK9h/yUd2EqroaZHnWha/j/qGcPkEnxbmxGw28Takzyx1vCo2H4bC5NI4/ogx8nPTGbHBJ4RSMNYNXDmNjbjUuapYavH2lbR0/WcE76OoKJVJSLEvPI/135k5cT38g+fzWadj0bvd6G30ERa/LSMFtqyreqR84c9bRWk0E/Tco2kXl85dsgL5bV3rVjxN1p9F6FapcxG1Lv9/y0svsyljdilP+OEFvuwzunv2q88j88YRmHN2vIoqUdvPFy8JO/h75NGodk2LS/K3FTXj8cBV6ysOXe6QNd6J4Q3VAonYQvTrrZF128A01FQElffnI3JG0a0KmZ2TkjyFpDwBCOLR4FK0skPGybZWpT51dKFFSHsFxO9c1JX7Rfxc+ERiVBuE89ORQUam9M6vWJ7b0jpkGbRFMp3/+BhK8bPfsfzEN1vEsTN0Zp+7wuvahc/LMfBbmwhgX+g39NiBogj5Gc8zMUC2hwp9vv7aF2IpkdxGau5T90JU5595V/cvJKukw6F5HWTcHgFFyiHW/oRl04rjDRXO5ERRzKHgHBeFSyfg2LHpm71mrhVon0zoZyGpAvkNjU7r33/8MaI0/q5X7aiFqqR4ZwXQSdxLyUrebcskX6oj7WpMFGV5iZYlS5yLXN7k2MWQQfotUFxyc W2eTjXhzOVzjfTISZ7OosQcBMQ/deu07XjlvMxfUUGIEcsRByHsRViR92kw/nIoOPGF7idJp0EarHOj/j9gr2m9W7xzXUb14EN X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 3fcb34d5-6da4-43d1-b7f8-08d9a955c70f X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2021 23:06:52.8964 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 26dilNIjxzC4Sx2ftQHnMbNjrl7vPxsygomaR1q3nlC+egqKZ6jER9u3/y13e4sy9sjyKAnr7GO0WxX/JZrUFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB5473 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:220164 Archived-At: On 11/16/2021 12:45 PM, Eli Zaretskii wrote: >> From: Ken Brown >>>> We certainly don't want to always skip the select call, but would it make sense >>>> to use a very short timeout for select in that case? Or maybe someone has a >>>> better idea. >>> >>> Making timeout shorter might be the solution, but I'd like to >>> understand the problem better first. > > If the code is based on the premise that we check for selection when > we exit select, then I think on systems without USABLE_SIGIO we should > call wait_reading_process_output with a short timeout but in a loop, > so that the summary wait is still 2 sec, but we exit the loop as soon > as selection arrives because each call to wait_reading_process_output > has a much shorter timeout, say, 25 msec. WDYT? Are you talking about having x_get_foreign_selection call wait_reading_process_output in a loop? That would fix this particular bug, but I was thinking of trying to solve a more general problem. Namely, whenever wait_reading_process_output is polling for input, avoid getting stuck in select, something like this: diff --git a/src/process.c b/src/process.c index f923aff1cb..808bf6f1ff 100644 --- a/src/process.c +++ b/src/process.c @@ -5588,6 +5588,15 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, timeout = make_timespec (0, 0); #endif +#ifndef USABLE_SIGIO + /* If we're polling for input, don't get stuck in select for + more than 25 msec. */ + struct timespec short_timeout = make_timespec (0, 25000000); + if ((read_kbd || !NILP (wait_for_cell)) + && timespec_cmp (short_timeout, timeout) < 0) + timeout = short_timeout; +#endif + /* Non-macOS HAVE_GLIB builds call thread_select in xgselect.c. */ #if defined HAVE_GLIB && !defined HAVE_NS nfds = xg_select (max_desc + 1, Ken