From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id A25E53858D28 for ; Tue, 11 Apr 2023 20:15:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A25E53858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmKOp-0001VJ-5W; Tue, 11 Apr 2023 16:15:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=9yGF9BOh0rNzVwvsW6V1W/k1DTv+AVJie92gTvdNDy8=; b=EbMFKG51Q9/ZXCw2NGAZ S5mM0lOud2JoVYg9idhcRMFQ5xo7xwCZaHSyjmjX9eudFkwWa+1tNXvzv+hnOfv4oQUvlw10s4ABk DZ5p4mrvxWFunSvapxfpRlhbjMfABvFhXxe+z8IiQVO9ySEt8mTteFYR9QE1NOgwKFAG2WYLX5prh Ve+vmAA5Tg2oABfe3shcIaz7ht5ZF2uMW3ogcpbqRu3B+IzWegOW0SI+nUxhjnyKOfhetQHRb5YgM TRpszCaqpFOGnUYGlx95YIbXtnG59APogeLZtFphrfMPwDfcyJLzbduRzYeGQNM83u4ozOGjBoq9C 6wua7XpGF3rIZw==; Received: from [2a01:cb19:4a:a400:de41:a9ff:fe47:ec49] (helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmKOo-0006aB-Ej; Tue, 11 Apr 2023 16:15:30 -0400 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pmKOm-000h9g-0W; Tue, 11 Apr 2023 22:15:28 +0200 Date: Tue, 11 Apr 2023 22:15:28 +0200 From: Samuel Thibault To: Sergey Bugaev Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: Re: [RFC PATCH glibc 25/34] hurd: Improve reply port handling when exiting signal handlers Message-ID: <20230411201528.pijuosntav2jcskh@begin> Mail-Followup-To: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org References: <20230319151017.531737-1-bugaevc@gmail.com> <20230319151017.531737-26-bugaevc@gmail.com> <20230410220311.fecuaj4gicx3hh5l@begin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sergey Bugaev, le mar. 11 avril 2023 10:44:17 +0300, a ecrit: > On Tue, Apr 11, 2023 at 1:03 AM Samuel Thibault wrote: > > I tend to be very cautious with reply port reuse since it can confuse > > servers a lot when e.g. interrupted, so it's generally safer not to try > > to reuse them. > > Huh? Confuse how? On interruption, it's hard to know whether the server will actually send a message on the reply port or not, in the end. So if you re-use a reply port but unfortunately the server sent a reply on it in the end, you get all reply messages shifted. > But I don't see a reason to destroy the *current* reply port, the one > used during signal handling, which we're longjumping out of. Simplicity. I agree that it should work fine as of now. But then somebody contributes something, doesn't notice that case, breaks it and mayhem comes, but only rarely since signals don't happen often. > On the other hand it doesn't hurt much either, and signal handling is > a slow path anyway, so we may just play it safe. Yes, please :) Samuel