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: Mon, 15 Nov 2021 14:26:08 -0500 Message-ID: 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> 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="13010"; 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 Mon Nov 15 20:27:21 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 1mmhdJ-0002xL-HL for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Nov 2021 20:27:13 +0100 Original-Received: from localhost ([::1]:55806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mmhdH-0000jV-5V for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Nov 2021 14:27:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmhd8-0000hy-LR for bug-gnu-emacs@gnu.org; Mon, 15 Nov 2021 14:27:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44658) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mmhd8-0004EW-Bw for bug-gnu-emacs@gnu.org; Mon, 15 Nov 2021 14:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mmhd8-0006mj-9I for bug-gnu-emacs@gnu.org; Mon, 15 Nov 2021 14:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Nov 2021 19:27:02 +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.163700438726024 (code B ref 50043); Mon, 15 Nov 2021 19:27:02 +0000 Original-Received: (at 50043) by debbugs.gnu.org; 15 Nov 2021 19:26:27 +0000 Original-Received: from localhost ([127.0.0.1]:56204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmhcY-0006lf-Hw for submit@debbugs.gnu.org; Mon, 15 Nov 2021 14:26:26 -0500 Original-Received: from mail-co1nam11on2131.outbound.protection.outlook.com ([40.107.220.131]:51424 helo=NAM11-CO1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmhcW-0006lP-Iz for 50043@debbugs.gnu.org; Mon, 15 Nov 2021 14:26:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S1FQ3RtfRmyqg8d6n/+bfbmGcZDQLltAVukoe1UaQzZG3M60aijwJE2jD4lRfA0WoqNhCHCNgSLD1zOzRyA+CdGh0HSnT81ohhSPu3O7tV9S8j6ECspFPkADlRg6NFh/+rDgT5hueWsIAwmXkl9bLLpWx9ZnKxIeE/4tpdkcNx7JK/c1LWK3pWGTWe0vrCELCesk0zJN1rYGtjm3iY6FwEXlGNlE/rwWQcj49CpLy0GpCazZCqy33Ka/hNJ45pCwZe5TN3OJ/pwCp2qRLuiU4agnXoGv6Ms8EhzvCZsXjjK9mMOwztDiVfVQ1JLPO65YMxXR8xIxSMAn8HAGHZSPqQ== 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=B2FbVXnpyjpms60Y5ONXqUGLPlnrWKi7vc5NfUHt5AI=; b=LVZKtCJmA2oH5fBpwT37nUiImQEMW1fkd9RoHt85AAleBMbw28N4lD3wNBEoGtdW9+GtLr1RJP8bttOmS0J6gUgB5kmjzYXXtLm1CXeHo+piOOA1/VEScZMBQ2NT4u+kT7Z00EeAsLmTiAAdAYEzN7mLzii40Dcvw2OFZxsCIenOSiuyE7q3cOlJol8o7xDJ+ySs1CSkyTQ7aO6hyIL3H8S1nIUi9wBCQwgGt5KIx6qrV8b/QA4hfzYX6XbaR8zyo4BGPPAW3RrM5RJ1SQEpix02tykhVI79D8UZw7teIj1jBE0q8YfpmOla3VvecBosU9n9X5Gt8gTk6gbFmgR52g== 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=B2FbVXnpyjpms60Y5ONXqUGLPlnrWKi7vc5NfUHt5AI=; b=AidARC7MfHLwSRsyGPDIy110t/9DhRWtZRNa9kg7LysF6raXbTABpG2BKzl3+KNc7x02RR3JMqI9kZ4hVHq9gbnYiEdlm1trJtf6uMyfx3qABmByxTPf52OoAgzhU7yo7FAgYMoU3imN5WNmZq1hKwOU7dtJkNa/VEYovLw6JI4= 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 BN6PR04MB0899.namprd04.prod.outlook.com (2603:10b6:405:40::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.27; Mon, 15 Nov 2021 19:26:10 +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; Mon, 15 Nov 2021 19:26:10 +0000 Content-Language: en-US In-Reply-To: <83czn12uz1.fsf@gnu.org> X-ClientProxiedBy: CH2PR17CA0001.namprd17.prod.outlook.com (2603:10b6:610:53::11) To BN7PR04MB4388.namprd04.prod.outlook.com (2603:10b6:406:f8::19) Original-Received: from [IPV6:2603:7081:7e3f:3419:ed13:ba2f:38dd:9fd1] (2603:7081:7e3f:3419:ed13:ba2f:38dd:9fd1) by CH2PR17CA0001.namprd17.prod.outlook.com (2603:10b6:610:53::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.26 via Frontend Transport; Mon, 15 Nov 2021 19:26:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a876d56d-01be-4cb4-f170-08d9a86dc746 X-MS-TrafficTypeDiagnostic: BN6PR04MB0899: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rlBJLdMdjYKsJciBZc17yeO59OWCG9LxugfjV9T7AhxBVO433KtH/baCYdr6FrKCY9QEGfiXn4r4f0OzQs+bQIKmoYmHPRSJ3rx4BBxw4jQ1D1lo7r1GLN9tNuBZI62MU9t3rAgqhEvCorKkVboGAtmtRybcK9bjteKQK282mjJEKI+gcVTdiMQuuNYpjB+rLn0WenzMgYaAYbnMhs5yN9cwIgGz5LC9ZLhZHPNnmmRz6k0V53lFXH5G1xZSdCZuMLtuJAT/HD/ncDf2nSBhirGoIDppNXBEdk0PDtRJYSwO0bvdTdDuLOtDm9S389E0feefdRJAPwxMIbFwv3uFNFQ8byj3lLee901zGcJdX84CabMZHgG8UbNU468OQMWL26BNTQ0rUltuJQheWZVhSFp9dNkE4BxGIxL1Ttr3v1xORmcxThmiyZvCW7wAlp6r7qjVAeaOaeFKFknk+sZHrsl/k4ZjPAlv5kxVWEwRPuPwWNhppBG8IcMqAbu23K70dG8VJrhi1ZYPOHIE60j8ZHLwxsC/XgItOr9ulqMifYEmcWGwRMHUi44qFmIhMLuFGO/mIAf65f/pk3KXx8ilTDrs/QnrtNY+mBT29pa+eQboDwTNMoFUElgoO5VX7JTzzmhWIVs4Ii1Wv+cpb7dbr9OUjLlXcqEK9HSulZ8LQK3Ir9rLZD5sZPCnsD9ctP5UXlTliv30XF0kjDddij4EM2BrVI407Im4BoXVuRP/+BQ= 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)(8936002)(2906002)(53546011)(36756003)(66476007)(86362001)(4326008)(186003)(2616005)(5660300002)(66556008)(8676002)(75432002)(31686004)(38100700002)(316002)(66946007)(83380400001)(6486002)(508600001)(6916009)(31696002)(786003)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 5DA/6jRMVy9KpJg29/AtJ//6eVMU1anXOHLQwT5i2ROAy9z7qUG7jurMA+lNXD0K7QWxOTm9iWTfTt7HBivB762Skhvu44FQbBh+U5cpNKDhdaRBpPHTy3TX0/pEwiiHoiOA64yDsYw9fEedRcPbhzdkcQtoczCiBZSG/ooWHj7N4p9/UCdgFbeUU7J0stSdnletzoGMc2//IhjHkCsvhbOzaIDMRObtaPnTqyQX4u6MsLRzEeeKV6o7gQZ+7u8UE0z77ZLIpG1gs4GsKxy28jLF2bQFHI6epQSCb5f48wPSfWKNPi1J8CtmONa4cbDrIR2mRJSzIiRLZIyfN5ueJMuFy2V09Y/kYHVucif+eAQR9bjE3jY1azTuzkoojP2B1NvzKxCxpRf92vN1KTZ43U0jp7RyyX9x8zarA8eP4jZTdOFyaD0BfobsnwkVDEJwr0Da8mUBtqNw3OebfSXBBp3UibZO1O27qXUS/OO7kY5p1al/N4BnDTbIL0YmUeF4J+0Hr1MHN9fV9Qpf1aiAGPb9CvPXJo7BersghS1ryC9CwitzjMUpDRWOdLC/x2qDc+3qJfEbzb8D8Qgr+t4VwRai5X4ikkSdXVk8qIWpioZF/6uCobTW7hdmy35KqnxSzj5PHkRLfqDT/0UvRqGU4Y0yOLAHDvq1moQbNtHA9ZRunhdWukU+bIZ3QRfUtGU12PxhBexe7oQuD4lVQQSQlTzebHpn1E09SYVg8VfFAejPsEWXejvyQg5y/I Qg93Ixg4/71xfUAHaVeHNeJaTEpqN1FnLTnxHJuyO2egS2zov+DIwpd09rzhf8nVf6ZdPCLrPqmqdxoC8KxHXs/i9dYQd06ZMa X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: a876d56d-01be-4cb4-f170-08d9a86dc746 X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2021 19:26:09.8982 (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: VyjEY6uSpsxZk1MGF2iO2b2KBFzlCWoBWv7KpNvUwILyvRsmmak6/acZdPbGlyITbeZOuRgpGEtJzljkeN9ZoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB0899 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:220082 Archived-At: On 11/15/2021 12:24 PM, Eli Zaretskii wrote: >> Date: Mon, 15 Nov 2021 10:19:32 -0500 >> Cc: 50043@debbugs.gnu.org >> From: Ken Brown >> >> x_get_foreign_selection (Lisp_Object selection_symbol, Lisp_Object target_type, >> Lisp_Object time_stamp, Lisp_Object frame) >> { >> [...] >> wait_reading_process_output (secs, nsecs, 0, false, >> reading_selection_reply, NULL, 0); >> >> I think wait_reading_process_output gets stuck for 2 seconds in a call to select >> (actually xg_select because I'm testing a gtk build). This is independent of >> the fact that x-selection-timeout is 2 seconds; it happens even if >> x-selection-timeout is 0. select returns after 2 seconds because the poll_timer >> fires. > > Sorry, I don't understand: select waits for up to 2 seconds because > that's what we ask it to do, and those 2 sec do come from > x-selection-timeout. If x-selection-timeout is zero, select is not > supposed to wait at all, so why does it? What am I missing? Setting x-selection-timeout to zero actually makes the timeout infinite: if (time_limit < 0 || nsecs < 0) wait = MINIMUM; else if (time_limit > 0 || nsecs > 0) { wait = TIMEOUT; now = current_timespec (); end_time = timespec_add (now, make_timespec (time_limit, nsecs)); } else wait = FOREVER; <<<<<<<<<<<<<<<<<<<<<< If x-selection-timeout is zero and you really want select to use a timeout of zero, you have to specify a negative value for nsecs. [This strikes me as very counterintuitive and a poor design decision.] x_get_foreign_selection should probably be changed to account for this, since the default value of x-selection-timeout is in fact zero, and clearly the intention was not to have an infinite wait in this case. There's a comment in x_get_foreign_selection that says "don't wait forever". >> On systems with SIGIO, select returns as soon as X events occur, because >> SIGIO is signaled. > > Which X event is that? something related to Emacs and selections, or > just a random event which simply happens at that time? I guess it's whatever X event is supposed to come in reply to the call XConvertSelection (display, selection_atom, type_atom, target_property, requestor_window, requestor_time); in x_get_foreign_selection. I don't anything about how I/O works under X, so I can't be more specific. > Anyway, AFAIU, the wait is supposed to end because XTread_socket reads > a SelectionNotify event, and that modifies the cell for which we > wait. What I'm not sure I understand is how are we supposed to call > XTread_socket when we are stuck inside select all the time? We're never stuck for more than 2 seconds [when there's no SIGIO] because poll_timer fires and either sends SIGALRM or makes timerfd read ready. Either way, select returns, and the next iteration of the main loop checks for input and checks for a cell change. >> 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. Ken