From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-125772-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 58571 invoked by alias); 1 Sep 2015 14:36:03 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 58561 invoked by uid 89); 1 Sep 2015 14:36:03 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO: mtaout20.012.net.il
Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Sep 2015 14:36:01 +0000
Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NU0004005PG8U00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Tue, 01 Sep 2015 17:34:57 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NU0003DT5U8UMC0@a-mtaout20.012.net.il>; Tue, 01 Sep 2015 17:34:57 +0300 (IDT)
Date: Tue, 01 Sep 2015 14:36:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: [RFC] Block all async signals used by gdb when initializing Guile
In-reply-to: <CAP9bCMSC3-NKPptfdisum8Au50yF_LbFb9e2sP6jfGxNPOZSDA@mail.gmail.com>
To: Doug Evans <xdje42@gmail.com>
Cc: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org, guile-devel@gnu.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83lhcqcin7.fsf@gnu.org>
References: <m3r3mmdn7g.fsf@sspiff.org> <831tel3o68.fsf@gnu.org> <CAP9bCMQmWmbLg9qZ3ZyVyTF=fBOB-sJtFAr1=OCC_g53aGYRUw@mail.gmail.com> <83wpwd26lt.fsf@gnu.org> <CAP9bCMRh+y4aNzgOThff5syzGs5-i2XpcbLVYw5G1avgd4QVvA@mail.gmail.com> <201508292104.t7TL42OS020892@glazunov.sibelius.xs4all.nl> <83si711oyo.fsf@gnu.org> <CAP9bCMSC3-NKPptfdisum8Au50yF_LbFb9e2sP6jfGxNPOZSDA@mail.gmail.com>
X-IsSubscribed: yes
X-SW-Source: 2015-09/txt/msg00012.txt.bz2

> Date: Mon, 31 Aug 2015 22:05:59 -0700
> From: Doug Evans <xdje42@gmail.com>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, 
> 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, guile-devel <guile-devel@gnu.org>
> 
> On Sat, Aug 29, 2015 at 7:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST)
> >> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> >> CC: eliz@gnu.org, gdb-patches@sourceware.org, guile-devel@gnu.org
> >>
> >> I suppose blocking these in the threads that guile starts is necessary
> >> because that is the only way to guarantee that those signals will be
> >> delivered to the main gdb thread on POSIX systems.
> >>
> >> On Windows you probably need to do something completely different.
> >
> > I might be missing something, because I don't see why.
> 
> The goal here is to block these signals from being sent to the threads
> that Guile (or more specifically libgc) creates.

Why only libgc?  Don't we want to block these signals in any Guile
code invoked later by GDB?

> Not sure how to do that on windows.

That problem doesn't exist on Windows, but what about Guile
application threads launched later?