From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5ipbC1mR2GCabwAAWB0awg (envelope-from ) for ; Sun, 27 Jun 2021 10:55:21 -0400 Received: by simark.ca (Postfix, from userid 112) id 1C43F1F1F2; Sun, 27 Jun 2021 10:55:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=MAILING_LIST_MULTI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B797F1E939 for ; Sun, 27 Jun 2021 10:55:19 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2073B3857819 for ; Sun, 27 Jun 2021 14:55:19 +0000 (GMT) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by sourceware.org (Postfix) with ESMTPS id 6A6DE3857808 for ; Sun, 27 Jun 2021 14:55:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6A6DE3857808 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f52.google.com with SMTP id w13so9483300wmc.3 for ; Sun, 27 Jun 2021 07:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZQfAk4xytrvecLQE239HGADQLr+lgRDrsHhdvHQOhUo=; b=KuEoWIZjwsgZzG6iu90wpcDYvzoEvzcUr+Z7EqoqVg3T80SZtmIaK3KVr7SX/38EHK BybKmU440O950yClA7z4rfnyPaaaaOFl9dFNsCgEMXepddFMuyXQG3hVGDcNExq0mh1j 7Fkdu8VYX02K79ABBBBH8KwmKnNXIjUY7QoXGo6lORJaqFfJNP0DdtYwS2vj1fKBS6w6 vyGfTFBpul4nQ7EW92kuMJ2Egm0cw6HDFXa/9nFaxKHi/hyrHMroBZ1Jrvw8G5qiRMvV SW9c0R0i4IyzijXLJTbqO87XlyZwoU0Sme6m8lx1k3EAFZDWe0szdbJji57NXnKzdX/o 8jxg== X-Gm-Message-State: AOAM532Qa8UPlfqGNvfTglTnUMaBQIELdWL79GIyJyxNC9U7TnBcAd2d vuutlP8pDtYmRXdBgjuZIIj1SmkdUnPy5Q== X-Google-Smtp-Source: ABdhPJx8/I4AmekAdTFDP2I0EQBU7dOgCA1F0k+ZoP38c3Ac9wq5ncaap8zEKWGq4X3t3PYqua8oBw== X-Received: by 2002:a05:600c:49a4:: with SMTP id h36mr6761144wmp.122.1624805705907; Sun, 27 Jun 2021 07:55:05 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3? ([2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3]) by smtp.gmail.com with ESMTPSA id s1sm16710880wmj.8.2021.06.27.07.55.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Jun 2021 07:55:05 -0700 (PDT) Subject: Re: [PATCH 3/4] scoped_ignore_signal: Use sigprocmask+sigtimedwait instead of signal From: Pedro Alves To: John Baldwin , Simon Marchi , gdb-patches@sourceware.org References: <20210615111429.1879286-1-pedro@palves.net> <20210615111429.1879286-4-pedro@palves.net> <6dca033a-1b6f-05df-8dd0-e1cc2c7d85d2@FreeBSD.org> Message-ID: <5f2c10b5-035f-b66d-77c0-c141cc0e9d0c@palves.net> Date: Sun, 27 Jun 2021 15:55:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <6dca033a-1b6f-05df-8dd0-e1cc2c7d85d2@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2021-06-26 2:41 p.m., John Baldwin wrote: > On 6/26/21 5:35 AM, Simon Marchi via Gdb-patches wrote: >> On 2021-06-15 7:14 a.m., Pedro Alves wrote: >>> The problem with using signal(...) to temporarily ignore a signal, is >>> that that changes the the signal disposition for the whole process. >>> If multiple threads do it at the same time, you have a race. >>> >>> Fix this by using sigprocmask + sigtimedwait to implement the ignoring >>> instead, if available, which I think probably means everywhere except >>> Windows nowadays.  This way, we only change the signal mask for the >>> current thread, so there's no race. >> >> I tried to build on macOS today and got: >> >> >>        CXX    compile/compile.o >>      In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46: >>      /Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait' >>                sigtimedwait (&set, nullptr, &zero_timeout); >>                ^ >> >> I didn't have time to dig yet. > > It looks like macOS doesn't implement either sigtimedwait() or sigwaitinfo() > which are part of POSIX from 1996 (*sigh*); however, macOS does provide > sigpending() and sigwait(), so perhaps we can do something like: > >    if (ConsumePending) >      { > #ifdef HAVE_SIGTIMEDWAIT >        const timespec zero_timeout = {}; > >        sigtimedwait (&set, nullptr, &zero_timeout); > #else >        sigset_t pending; > >        sigpending (&pending); >        if (sigismember (&pending, SIG)) >          sigwait (&set, nullptr); > #endif >      } > Thanks, that looks right to me. We're using sigtimewait with zero timeout to consume a pending signal. sigpending + sigwait effectively does the same thing. According to gnulib, sigpending exists everywhere but mingw: https://www.gnu.org/software/gnulib/manual/html_node/sigpending.html and sigtimedwait is missing on "Mac OS X 10.13, OpenBSD 6.7, Minix 3.1.8, Cygwin 2.9, mingw, MSVC 14, Android 5.1.": https://www.gnu.org/software/gnulib/manual/html_node/sigtimedwait.html So the approach you propose should work well. Given sigpending is everywhere Unix-like, if we'd like, we could instead use the sigpending + sigwait path unconditionally everywhere, but that's two syscalls instead of one, and the configure check is trivial (just add sigtimedwait to AC_CHECK_FUNCS in gdbsupport/common.m4), so why not indeed save one syscall, seems easy enough. Let me know if you'd rather me do the leg work of writing the actual patch. Pedro Alves