From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73220 invoked by alias); 1 Jul 2016 16:45:37 -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 73206 invoked by uid 89); 1 Jul 2016 16:45:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=queued X-HELO: mail-oi0-f66.google.com Received: from mail-oi0-f66.google.com (HELO mail-oi0-f66.google.com) (209.85.218.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 Jul 2016 16:45:31 +0000 Received: by mail-oi0-f66.google.com with SMTP id w141so13597425oia.0 for ; Fri, 01 Jul 2016 09:45:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ynANP6y4ysJ62vMoV2g7xGmx8O0VAjMultM12oH80Ao=; b=AbRMrKeH6O+EK2acMyCO3bzg3r3/8A1sSUGFPtn9o7zdwnlUViN95obAp1BVUwyFH3 AmB8SuKlyZlxHZ9G4ULy6uN0qSsvHpn3drvZxLAfjLgQXlcMwsQvUK+ytKrBr3hPbsf2 QgUpMKIBC/UM86IfkJIu+B41FV57sRhQzYP1ZWw+oVrlt+eFCo/t2IIkzKyz9kSY0fBM hyIhyWpc+pueQN1VVQSyuGM7s3ndlwUh2luRh4hlM/84JxpqLq1MQuWPrjTWMabRHWrZ XmAwp4Fk0RdI4drGaIyKJSqv9Gx7DiapYDC5yEoDMOUgUtMBoYhPDurjzqAf9gY+OoAK IFUw== X-Gm-Message-State: ALyK8tK7WyaUCAOlTOkByskQpU3nBBov0s+HCtPwdn+u2EqkeMRq5CrM81rzQ/oFP35RrFzNPhVUjnKKElF4+A== X-Received: by 10.202.217.67 with SMTP id q64mr12714187oig.12.1467391529962; Fri, 01 Jul 2016 09:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.182.130 with HTTP; Fri, 1 Jul 2016 09:45:29 -0700 (PDT) In-Reply-To: <4a3c91d8-85bb-31f2-7f9e-bc0fe0de0ff6@redhat.com> References: <1467295765-3457-1-git-send-email-yao.qi@linaro.org> <1467295765-3457-8-git-send-email-yao.qi@linaro.org> <4a3c91d8-85bb-31f2-7f9e-bc0fe0de0ff6@redhat.com> From: Yao Qi Date: Fri, 01 Jul 2016 16:45:00 -0000 Message-ID: Subject: Re: [PATCH 7/9] Enqueue signal even when resuming threads To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00015.txt.bz2 On Fri, Jul 1, 2016 at 4:06 PM, Pedro Alves wrote: > On 06/30/2016 03:09 PM, Yao Qi wrote: >> Nowadays, we only enqueue signal when we leave thread pending in >> linux_resume_one_thread. If lwp->resume->sig isn't zero (GDB wants >> to resume with signal), we pass lwp->resume->sig to >> linux_resume_one_lwp. >> >> In order to reduce the difference between resuming thread with signal >> and proceeding thread with signal, when we resume thread, we can >> enqueue signal too, and proceed thread. The signal will be consumed in >> linux_resume_one_lwp_throw from lwp->pending_signals. > > This makes one subtle change. If the thread already > had a pending signal, and we're getting a resume request with > a signal that is a different signal from the one already queued, > then before the patch, we'd tell the kernel to deliver the new > signal first, and then only deliver the pending signal the next time > the thread is resumed. While after the patch, we'll enqueue the > new signal, and deliver the one that was already pending first. > > Can't really say whether the old behavior was necessary. At least > the new behavior seems to make order or signal delivery consistent > with how the order the signals were made pending in the > first place, so seems better. > > This made me notice that this scenario of having more than one > pending signal doesn't seem to be handled perfectly. We deliver > the first signal, but nothing makes sure to get back control > of the thread immediately in order to deliver the other pending > signal, so it seems the thread may execute a bunch of arbitrary code > until it next stops and is re-resumed, at which point we'll deliver > the other pending signal. Maybe the simplest would be to > force the thread to immediately stop again, by calling > send_sigstop before resuming it, whenever we have more pending > signals. Subject for a separate patch, in any case. You meant "after resuming it" rather than "before resuming it", right? We = have two pending signals, so we resume the lwp and deliver the first signal. Af= ter resuming, we need to immediately deliver the second signal, so we call send_sigstop. IIUC, this patch is OK as-is, right? --=20 Yao (=E9=BD=90=E5=B0=A7)