From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9565 invoked by alias); 18 Feb 2014 16:45:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9553 invoked by uid 89); 18 Feb 2014 16:45:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: hera.aquilenet.fr Received: from hera.aquilenet.fr (HELO hera.aquilenet.fr) (141.255.128.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2014 16:45:32 +0000 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 43F561BF9; Tue, 18 Feb 2014 17:45:30 +0100 (CET) Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWycJQx2l9N8; Tue, 18 Feb 2014 17:45:30 +0100 (CET) Received: from pluto (LDijon-156-64-49-137.w217-128.abo.wanadoo.fr [217.128.51.137]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 4E56C91D; Tue, 18 Feb 2014 17:45:29 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Eli Zaretskii Cc: xdje42@gmail.com, gdb-patches@sourceware.org, guile-devel@gnu.org Subject: Re: [PATCH v2] Improved ^c support for gdb/guile References: <834n3x8o7m.fsf@gnu.org> <83y519788a.fsf@gnu.org> <871tz0d5vc.fsf@gnu.org> <83iosc76kz.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 30 =?utf-8?Q?Pluvi=C3=B4se?= an 222 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Tue, 18 Feb 2014 16:45:00 -0000 In-Reply-To: <83iosc76kz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Feb 2014 18:01:48 +0200") Message-ID: <87txbw9xp4.fsf@gnu.org> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-02/txt/msg00569.txt.bz2 Eli Zaretskii skribis: >> From: ludo@gnu.org (Ludovic Court=C3=A8s) >> Cc: Eli Zaretskii , gdb-patches@sourceware.org, guile-deve= l@gnu.org >> Date: Tue, 18 Feb 2014 12:20:39 +0100 >>=20 >> Doug Evans skribis: >>=20 >> I don=E2=80=99t remember, Eli: do you have patches pending review for th= ese >> issues and other MinGW issues in Guile? > > I don't know, you tell me. I sent several changesets in June, > in these messages: OK, will follow-up on guile-devel. >> The non-pthread code is used when Guile is built without pthread >> support. In that case, the async is queued directly from the signal >> handler. > > So why cannot this code be used by GDB? Because GDB uses whichever Guile is available. If the user has Guile built with pthread support, then that=E2=80=99s what GDB uses. >> (I think we should aim to get rid of the signal-delivery thread >> eventually, and I remember Mark mentioned it before too.) > > Right, which raises again the question why use in GDB something that > is slated for deletion. I think there=E2=80=99s a misunderstanding. Doug=E2=80=99s signal-delivery= thread will work no matter what strategy Guile uses internally. My comment above was referring to Guile=E2=80=99s internal implementation of signal delivery, which does not affect what GDB does. > Btw, where does the value of SCM_USE_PTHREAD_THREADS come from? Is it > something defined by the installed Guile headers? Yes, and determined at Guile configure time. Ludo=E2=80=99.