From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.comp.gdb.patches,gmane.lisp.guile.devel Subject: Re: [PATCH v2] Improved ^c support for gdb/guile Date: Tue, 18 Feb 2014 12:20:39 +0100 Message-ID: <871tz0d5vc.fsf@gnu.org> References: <834n3x8o7m.fsf@gnu.org> <83y519788a.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1392722444 6834 80.91.229.3 (18 Feb 2014 11:20:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Feb 2014 11:20:44 +0000 (UTC) Cc: Eli Zaretskii , gdb-patches@sourceware.org, guile-devel@gnu.org To: Doug Evans Original-X-From: gdb-patches-return-110462-gdb-gdb-patches=m.gmane.org@sourceware.org Tue Feb 18 12:20:50 2014 Return-path: Envelope-to: gdb-gdb-patches@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WFijK-00036V-DD for gdb-gdb-patches@plane.gmane.org; Tue, 18 Feb 2014 12:20:50 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=BsDx8tSpFuksrKJ2uUcpK6o6z8a6cKbXpaOlT9TS685 g8w7hH9+OSTYqlxewQnvmf9e8wvN0ItsmoO1K7Wn47Z0Ev9gaV9BDPOsoseLEKvG LIFa4m4r2MeisEJezEV++qo147PZwQduhZM/CKzypveQp9XeK619tXHZoiV5hUdA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=yQBlOkKGrf2n7Gf1LCMUo8vvB5M=; b=ZA8P4oya0Z4oW+BM7 hosTRPRDauao0g3eU/4/DuyaN5+oJLLYirnLDsNYVbWtNl8vSb7Zb29fRsI+s0vH wyUROvZHOvZGuBN4HSs9CUGjAjJl92YX7XOx+Bm9FPFV9OwlL4qAKdColg9SWRr3 ftXnJc3khetuvsmudp3FyTc+K0= Original-Received: (qmail 8885 invoked by alias); 18 Feb 2014 11:20:46 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: gdb-patches-owner@sourceware.org Original-Received: (qmail 8874 invoked by uid 89); 18 Feb 2014 11:20:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: hera.aquilenet.fr Original-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 11:20:43 +0000 Original-Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 4E6EFF32; Tue, 18 Feb 2014 12:20:41 +0100 (CET) Original-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 6KsIfPO2t9af; Tue, 18 Feb 2014 12:20:41 +0100 (CET) Original-Received: from pluto (eduroam-176a.sophia.inria.fr [193.51.208.176]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 07A7391D; Tue, 18 Feb 2014 12:20:40 +0100 (CET) In-Reply-To: (Doug Evans's message of "Mon, 17 Feb 2014 16:37:30 -0800") User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) 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 Xref: news.gmane.org gmane.comp.gdb.patches:95464 gmane.lisp.guile.devel:16879 Archived-At: Doug Evans skribis: > On Mon, Feb 17, 2014 at 1:13 PM, Eli Zaretskii wrote: >>> Date: Mon, 17 Feb 2014 12:59:22 -0800 >>> From: Doug Evans >>> Cc: "gdb-patches@sourceware.org" , guile-de= vel@gnu.org >>> >>> >> +void >>> >> +gdbscm_initialize_sigint (void) >>> >> +{ >>> >> + siscm_sigint_pipe[0] =3D siscm_sigint_pipe[1] =3D -1; >>> >> + >>> >> + if (!SCM_USE_PTHREAD_THREADS) >>> >> + { >>> >> + warning (_("Guile does not have pthreads support.")); >>> >> + warning (_("Proper SIGINT handling for Guile will be unavaila= ble.")); >>> >> + return; >>> >> + } >>> > >>> > The above is what worries me. Guile currently doesn't work in the >>> > native MinGW build if configured with threads (it crashes, hangs, >>> > etc.). Can't we have decent SIGINT handling without pthreads? I don=E2=80=99t remember, Eli: do you have patches pending review for these issues and other MinGW issues in Guile? >>> With 2.0.x, no. >>> I'm ok with changing the warning, e.g., not printing it at all on >>> systems where it would otherwise always be printed, and instead >>> documenting the issue for such systems. >>> >>> The downside is that while Scheme code is running SIGINT is ignored >>> (unless one is in the repl, or sets up a SIGINT handler oneself). >> >> Ignored why? because GDB sets the handler to SIG_IGN? Or for some >> other reason? > > A better way to phrase that is the SIGINT is deferred until the call > out to Guile returns. > Why? Because Guile's SIGINT handling in 2.0.x requires a separate > thread: that's how all async signals are handled in Guile. > ref: guile-2.0.9/libguile/scmsigs.c Right, when Guile is built with pthread support, it has a signal delivery thread. The actual SIGINT handler (=E2=80=98take_signal=E2=80=99 = in scmsigs.c) just write one byte to a pipe; the signal delivery thread reads from that pipe, and queues an async in the destination thread for later execution. > I'll let guile-devel take over at this point - I understand the code, > but may miss something noteworthy. > There is code in scmsigs.c to handle the non-pthread case but it's not > clear how much is exported nor how well it works. 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. (I think we should aim to get rid of the signal-delivery thread eventually, and I remember Mark mentioned it before too.) HTH, Ludo=E2=80=99.