This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 2/9] add "this" pointers to more target APIs
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 06 Dec 2013 18:35:12 +0000
- Subject: Re: [PATCH v4 2/9] add "this" pointers to more target APIs
- Authentication-results: sourceware.org; auth=none
- References: <1382464769-2465-1-git-send-email-tromey at redhat dot com> <1382464769-2465-3-git-send-email-tromey at redhat dot com> <526E8AF2 dot 7050202 at redhat dot com> <87r4b5cpxd dot fsf at fleche dot redhat dot com> <526E9451 dot 6050103 at redhat dot com> <87mwltcp8v dot fsf at fleche dot redhat dot com> <527D2323 dot 2010708 at redhat dot com> <87ob5uodry dot fsf at fleche dot redhat dot com> <527D5D58 dot 4030707 at redhat dot com> <87wqjhkhe4 dot fsf at fleche dot redhat dot 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