From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58330 invoked by alias); 25 Nov 2015 15:31:27 -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 58311 invoked by uid 89); 25 Nov 2015 15:31:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Nov 2015 15:31:26 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 66A6CCF92; Wed, 25 Nov 2015 15:31:25 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAPFVO0G028245; Wed, 25 Nov 2015 10:31:24 -0500 Message-ID: <5655D44B.4010906@redhat.com> Date: Wed, 25 Nov 2015 15:31:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 16/18] gdbserver/linux: Always wake up event loop after resume References: <1444836486-25679-1-git-send-email-palves@redhat.com> <1444836486-25679-17-git-send-email-palves@redhat.com> <864mhd1z16.fsf@gmail.com> In-Reply-To: <864mhd1z16.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00520.txt.bz2 On 10/26/2015 02:32 PM, Yao Qi wrote: > Pedro Alves writes: > >> Handle this in the same way nat/linux-nat.c:linux_nat_resume handles >> this. > > Nit, it is linux-nat.c instead of nat/linux-nat.c. In linux_nat_resume, > async_file_mark is guarded by lwp_status_pending_p (lp), so we need to > check whether there is an event pending in GDBserver too. I don't think we can just check whether there is an event pending in the current thread -- the pending event may be in any other thread that is now resumed from the client's perspective. As we'd have to walk all threads anyway, seems simplest to just unconditionally mark the event loop and let linux_wait & friends handle that. On the native side, we may have a latent bug and things work anyhow because something else always wakes up the event loop once. (E.g., nowadays target_async always marks infrun's event source.) Thanks, Pedro Alves