From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26707 invoked by alias); 6 Dec 2013 18:35:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 26695 invoked by uid 89); 6 Dec 2013 18:35:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2013 18:35:21 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6IZEUY018467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Dec 2013 13:35:14 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rB6IZC41006977; Fri, 6 Dec 2013 13:35:13 -0500 Message-ID: <52A218E0.9060205@redhat.com> Date: Fri, 06 Dec 2013 18:35:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: [PATCH v4 2/9] add "this" pointers to more target APIs References: <1382464769-2465-1-git-send-email-tromey@redhat.com> <1382464769-2465-3-git-send-email-tromey@redhat.com> <526E8AF2.7050202@redhat.com> <87r4b5cpxd.fsf@fleche.redhat.com> <526E9451.6050103@redhat.com> <87mwltcp8v.fsf@fleche.redhat.com> <527D2323.2010708@redhat.com> <87ob5uodry.fsf@fleche.redhat.com> <527D5D58.4030707@redhat.com> <87wqjhkhe4.fsf@fleche.redhat.com> In-Reply-To: <87wqjhkhe4.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00261.txt.bz2 On 12/06/2013 05:40 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves 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