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 5CC083858D3C for ; Wed, 1 Mar 2023 18:23:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CC083858D3C 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 1pXR6g-0006cJ-ME; Wed, 01 Mar 2023 13:23:14 -0500 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=S4vKnlaMlHqt0oAt3JcIExLQdAMjW/tGsNlT5Q/moqo=; b=Gq+tHBGMWAKIowlGbIHh momdZyYK+8hHEAgokHYQ/2tcJY/AFHvUeUVfjT/EJPEAMSrxGshwyfqvzTXe1QbHKVdNTFlNRgUG7 4sraTTPpww58+wNtoNUFS5vZPo9UAPdzctG7b1XesYQnyyQVS7Y+sjXdj84WJEUmsiKsuT8NSfGBr Cudy17RY8rRO4qDX3yoXAeg6gGN1yeuOKuOl8KTGatGX98gYZwTBhFgXlIJsNn4N6/8CGDQSmKp4/ lN4CNgmruF4PK7uNUgOP/pgvllR+D8Eo6O+NYao3naeMLTrbyxBqyN8RV08J+UAQ58DJTho/EvsW5 KT6Pe5o1VDWp+Q==; Received: from [145.131.240.227] (helo=begin.fritz.box) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXR6g-0006ur-FU; Wed, 01 Mar 2023 13:23:14 -0500 Received: from samy by begin.fritz.box with local (Exim 4.96) (envelope-from ) id 1pXR6e-002G98-0D; Wed, 01 Mar 2023 19:23:12 +0100 Date: Wed, 1 Mar 2023 19:23:12 +0100 From: Samuel Thibault To: Luca Cc: Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org Subject: Re: [PATCH 1/2] hurd: Remove the ecx kludge Message-ID: <20230301182312.oqrq4m7wjhf33npq@begin> Mail-Followup-To: Luca , Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org References: <20230301092421.x6derf2if5tc3u5u@begin> <20230301162355.426887-1-bugaevc@gmail.com> <44d91128-f2e4-8aa7-1801-bdecef7797cb@orpolo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44d91128-f2e4-8aa7-1801-bdecef7797cb@orpolo.org> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Luca, le mer. 01 mars 2023 19:01:02 +0100, a ecrit: > I still have to fully understand the existing code, so this might be > something completely wrong... but if interrupting an rpc is a complex thing > to do reliably in user space, why not add some kernel support? Also, how do > you test this code? Mach already provides support for interruption. But it cannot deal with the user code itself. One way could be to add a pointer to the mach_msg call for the kernel to check the cancel flag itself, but that becomes relatively dirty, compared to just dealing with the matter in userland, which on the other hand allows userland to introduce whatever interruption/cancelation/signal/etc. notions at will. > Also, if I understand correctly, in case the thread finished the syscall and > successfully received a message, but didn't return to userspace yet, isn't > there the risk of losing the message, with the current approach? IIRC that part is not interruptible, so either we get a message, or we get interrupted, but not both. Samuel