From: ludo@gnu.org (Ludovic Courtès)
To: Eli Zaretskii <eliz@gnu.org>
Cc: xdje42@gmail.com, gdb-patches@sourceware.org, guile-devel@gnu.org
Subject: Re: [PATCH v2] Improved ^c support for gdb/guile
Date: Tue, 18 Feb 2014 17:45:27 +0100 [thread overview]
Message-ID: <87txbw9xp4.fsf@gnu.org> (raw)
In-Reply-To: <83iosc76kz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Feb 2014 18:01:48 +0200")
Eli Zaretskii <eliz@gnu.org> skribis:
>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org, guile-devel@gnu.org
>> Date: Tue, 18 Feb 2014 12:20:39 +0100
>>
>> Doug Evans <xdje42@gmail.com> skribis:
>>
>> I don’t remember, Eli: do you have patches pending review for these
>> 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’s 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’s a misunderstanding. Doug’s signal-delivery thread will
work no matter what strategy Guile uses internally. My comment above
was referring to Guile’s 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’.
next prev parent reply other threads:[~2014-02-18 16:45 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <wrbvbwejihe.fsf@sspiff.org>
[not found] ` <wrbr471jxjg.fsf@sspiff.org>
[not found] ` <834n3x8o7m.fsf@gnu.org>
2014-02-17 20:59 ` [PATCH v2] Improved ^c support for gdb/guile Doug Evans
2014-02-17 21:13 ` Eli Zaretskii
2014-02-18 0:37 ` Doug Evans
2014-02-18 11:20 ` Ludovic Courtès
2014-02-18 16:01 ` Eli Zaretskii
2014-02-18 16:45 ` Ludovic Courtès [this message]
2014-02-18 16:56 ` Eli Zaretskii
2014-02-18 17:45 ` Ludovic Courtès
2014-02-18 17:59 ` Eli Zaretskii
2014-02-18 23:08 ` Ludovic Courtès
2014-02-18 17:32 ` MinGW patches Ludovic Courtès
2014-02-18 18:16 ` Eli Zaretskii
2014-02-22 10:33 ` [PATCH] Remove unneeded HAVE_POSIX conditionals Eli Zaretskii
2014-02-22 14:52 ` Mark H Weaver
2014-02-22 15:41 ` Eli Zaretskii
2014-02-26 21:42 ` Ludovic Courtès
2014-02-22 10:50 ` [PATCH] Implement open-process and related functions on MinGW Eli Zaretskii
2014-02-22 14:59 ` Mark H Weaver
2014-02-22 15:43 ` Eli Zaretskii
2014-02-22 15:54 ` Mark H Weaver
2014-02-22 16:35 ` Eli Zaretskii
2014-02-23 5:50 ` Mark H Weaver
2014-02-23 17:54 ` Eli Zaretskii
2014-02-24 18:33 ` Mark H Weaver
2014-02-24 21:06 ` Eli Zaretskii
2014-02-28 7:22 ` Mark H Weaver
2014-02-28 9:10 ` Eli Zaretskii
2014-02-28 10:20 ` Mark H Weaver
2014-02-28 11:26 ` Eli Zaretskii
2014-02-24 21:12 ` Eli Zaretskii
2014-02-22 18:20 ` Eli Zaretskii
2014-02-22 22:02 ` Mark H Weaver
2014-02-23 3:45 ` Eli Zaretskii
2014-02-23 4:40 ` Mark H Weaver
2014-02-23 17:46 ` Eli Zaretskii
2014-02-23 20:14 ` Mark H Weaver
2014-02-22 10:57 ` MinGW patches Eli Zaretskii
2014-02-22 12:23 ` Neil Jerram
2014-02-22 13:02 ` Eli Zaretskii
2014-02-22 11:06 ` Eli Zaretskii
2014-02-22 15:59 ` Mark H Weaver
2014-02-22 16:36 ` Eli Zaretskii
2014-02-23 14:21 ` Mark H Weaver
2014-02-23 18:06 ` Eli Zaretskii
2014-02-19 7:50 ` [PATCH v2] Improved ^c support for gdb/guile Mark H Weaver
2014-02-19 16:42 ` Eli Zaretskii
2014-02-18 17:31 ` Doug Evans
2014-02-18 17:42 ` Signal delivery Ludovic Courtès
2014-02-18 17:56 ` Doug Evans
2014-02-18 23:06 ` Ludovic Courtès
2014-02-19 1:58 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txbw9xp4.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=guile-devel@gnu.org \
--cc=xdje42@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).