From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108476 invoked by alias); 1 Jul 2016 15:06:38 -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 108424 invoked by uid 89); 1 Jul 2016 15:06:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=queued 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; Fri, 01 Jul 2016 15:06:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 76B4DC0624BA; Fri, 1 Jul 2016 15:06:28 +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 u61F6REl021448; Fri, 1 Jul 2016 11:06:27 -0400 Subject: Re: [PATCH 7/9] Enqueue signal even when resuming threads To: Yao Qi , gdb-patches@sourceware.org References: <1467295765-3457-1-git-send-email-yao.qi@linaro.org> <1467295765-3457-8-git-send-email-yao.qi@linaro.org> From: Pedro Alves Message-ID: <4a3c91d8-85bb-31f2-7f9e-bc0fe0de0ff6@redhat.com> Date: Fri, 01 Jul 2016 15:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1467295765-3457-8-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-07/txt/msg00012.txt.bz2 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. Thanks, Pedro Alves