Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v4 2/9] add "this" pointers to more target APIs
Date: Fri, 06 Dec 2013 18:35:00 -0000	[thread overview]
Message-ID: <52A218E0.9060205@redhat.com> (raw)
In-Reply-To: <87wqjhkhe4.fsf@fleche.redhat.com>

On 12/06/2013 05:40 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Tom> I think the in the long run it would be better if all targets were
> Tom> async.
> 
> Pedro> Yes, of course.  It requires per-target work, however...  I'm not
> Pedro> seeing that happen anytime soon.  (and djgpp might be a challenge.)
> 
> I wonder if we could simplify gdb by only providing async at the target
> API level, and then letting some targets still work synchronously under
> the hood, just using the async callback to report the event that was
> found.  It wouldn't let "&" work but it might simplify the internals.  I
> can't tell if this makes sense.

It's really hard for me to say.  It's the sort of thing that
requires experimentation, I think.

On the target side, supporting target_wait(0, ...) in addition
to target_wait(..., TARGET_WHANG) doesn't look that complicated
to me.  I think GDB will always need to do blocking target waits
on occasion, even on async targets.  I never imagined it tackled
at that level.  Hmmm.  I think there are several alternative levels/layers
where such a sync vs async normalization could occur.  Could be like you say,
or it could be one level up, that is, have infrun.c call blocking target_wait,
and infrun itself push the resulting event in a local pending event queue
that the event loop would react to.  Or it could be at the command levels,
making the sync paths also install the continuations and run then when
the target stops, though now that I spell it out, the latter one doesn't
sound like it'd remove as much differences as the former ones, I think.

-- 
Pedro Alves


  reply	other threads:[~2013-12-06 18:35 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 17:59 [PATCH v4 0/9] enable target-async by default Tom Tromey
2013-10-22 17:59 ` [PATCH v4 5/9] PR gdb/13860: make "-exec-foo"'s MI output equal to "foo"'s MI output Tom Tromey
2013-10-22 17:59 ` [PATCH v4 1/9] fix latent bugs in ui-out.c Tom Tromey
2013-10-28 15:20   ` Pedro Alves
2013-10-28 17:36     ` Tom Tromey
2013-10-22 17:59 ` [PATCH v4 4/9] PR gdb/13860: make -interpreter-exec console "list" behave more like "list" Tom Tromey
2013-10-22 17:59 ` [PATCH v4 3/9] add target method delegation Tom Tromey
2013-10-28 16:05   ` Pedro Alves
2013-10-28 17:51     ` Tom Tromey
2013-10-28 17:53       ` Tom Tromey
2013-10-29 20:55         ` Tom Tromey
2013-11-08 17:44           ` Pedro Alves
2013-12-11 22:03             ` Tom Tromey
2013-12-12  2:46               ` Tom Tromey
2013-12-13 22:07                 ` Tom Tromey
2013-12-16 13:07                   ` Pedro Alves
2013-12-16 21:21                     ` Tom Tromey
2013-12-17 16:17                       ` Pedro Alves
2013-12-18 18:29                         ` Tom Tromey
2013-12-18 22:06                           ` Tom Tromey
2013-12-19 16:03                             ` Pedro Alves
2013-12-19 16:15                               ` Tom Tromey
2013-12-20 19:24                                 ` Tom Tromey
2013-11-08 16:34       ` Pedro Alves
2013-10-22 17:59 ` [PATCH v4 2/9] add "this" pointers to more target APIs Tom Tromey
2013-10-28 16:04   ` Pedro Alves
2013-10-28 16:37     ` Tom Tromey
2013-10-28 16:44       ` Pedro Alves
2013-10-28 16:52         ` Tom Tromey
2013-11-08 18:04           ` Pedro Alves
2013-11-08 21:53             ` Tom Tromey
2013-11-09  3:35               ` Pedro Alves
2013-12-06 17:40                 ` Tom Tromey
2013-12-06 18:35                   ` Pedro Alves [this message]
2013-12-06 18:23                 ` Tom Tromey
2013-12-06 19:06                   ` Pedro Alves
2013-10-22 18:11 ` [PATCH v4 8/9] fix py-finish-breakpoint.exp with always-async Tom Tromey
2013-11-11 19:51   ` Pedro Alves
2013-12-09 17:53     ` Tom Tromey
2013-10-22 18:26 ` [PATCH v4 9/9] enable target-async Tom Tromey
2013-10-22 20:15   ` Eli Zaretskii
2013-11-11 19:54   ` Pedro Alves
2013-11-12 20:53   ` Pedro Alves
2013-11-15  0:45     ` Tom Tromey
2013-11-18 15:42       ` Pedro Alves
2013-12-06 20:44         ` Tom Tromey
2013-12-09 12:01           ` Pedro Alves
2013-12-09 15:57             ` Tom Tromey
2014-02-21 20:23               ` Tom Tromey
2014-02-24 17:38           ` Tom Tromey
2013-10-22 18:26 ` [PATCH v4 6/9] PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode Tom Tromey
2013-10-22 19:00 ` [PATCH v4 7/9] make dprintf.exp pass in always-async mode Tom Tromey
2013-11-12  0:05   ` Pedro Alves

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A218E0.9060205@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.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