From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Doug Evans Newsgroups: gmane.lisp.guile.devel,gmane.comp.gdb.patches Subject: Re: [PATCH v2] Improved ^c support for gdb/guile Date: Tue, 18 Feb 2014 09:31:00 -0800 Message-ID: References: <834n3x8o7m.fsf@gnu.org> <83y519788a.fsf@gnu.org> <871tz0d5vc.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1392744663 28922 80.91.229.3 (18 Feb 2014 17:31:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Feb 2014 17:31:03 +0000 (UTC) Cc: Eli Zaretskii , guile-devel@gnu.org, "gdb-patches@sourceware.org" To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 18 18:31:10 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WFoVg-0001c7-Jt for guile-devel@m.gmane.org; Tue, 18 Feb 2014 18:31:08 +0100 Original-Received: from localhost ([::1]:52071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFoVg-0006rN-7H for guile-devel@m.gmane.org; Tue, 18 Feb 2014 12:31:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFoVa-0006rH-T2 for guile-devel@gnu.org; Tue, 18 Feb 2014 12:31:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFoVa-00042a-2P for guile-devel@gnu.org; Tue, 18 Feb 2014 12:31:02 -0500 Original-Received: from mail-yh0-x234.google.com ([2607:f8b0:4002:c01::234]:53230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFoVZ-00042H-TC; Tue, 18 Feb 2014 12:31:01 -0500 Original-Received: by mail-yh0-f52.google.com with SMTP id a41so15589560yho.25 for ; Tue, 18 Feb 2014 09:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8n4+gwSSfkdZixHbeZ3uPWxKRhMeutRfJYv1BC5HJqg=; b=q1har9GNIwxJRZnEJebA+Z/5+kAJQJFwd2q+r+35vFZsHdF3cfEOaTToUl21iVKKax oVgoxmesdkouVb1g/NqpzPOCSiVw2kHv9iDMzRUeAeja9xIgf6zZ9Uwg3+JX0hKWA6jB 8DC4epj0Pqv9Cu5UZgrrx4oIOCs6HXW3d3leotY4Z+VMWiDeFlCVcuX4Q4YCmkif+31W +P4YsOg/w8u/8XfBU3Hx618FWWsirlzH8yYp+nBP4ZFyn00ZXtqssZvSrnrWNaRxOkZp pbQIfE69bzMLpY9Bdi2W7AOVSFPhWGWG8n5n92yKOZw0obt+92zZwHPJA1OCwHLMAlSO b5tA== X-Received: by 10.236.172.33 with SMTP id s21mr25642481yhl.71.1392744660751; Tue, 18 Feb 2014 09:31:00 -0800 (PST) Original-Received: by 10.170.130.14 with HTTP; Tue, 18 Feb 2014 09:31:00 -0800 (PST) In-Reply-To: <871tz0d5vc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c01::234 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16883 gmane.comp.gdb.patches:95474 Archived-At: On Tue, Feb 18, 2014 at 3:20 AM, Ludovic Court=E8s wrote: > Right, when Guile is built with pthread support, it has a signal > delivery thread. The actual SIGINT handler ('take_signal' 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.) Note that Python queues the asyncs directly from the signal handler, even when it has thread support. I'm not sure if there are any problems in Python's implementation; asyncs can be queued from any thread but only the main thread runs them. Guile would need to come up with its own implementation of course; plus Guile can direct signals to any thread.