From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by sourceware.org (Postfix) with ESMTPS id 11D653858419 for ; Mon, 11 Jul 2022 16:38:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 11D653858419 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f45.google.com with SMTP id z12so7752965wrq.7 for ; Mon, 11 Jul 2022 09:38:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dQTJagrw1YpSr4SMz5crqmtvblYSBVADkFUr2bXunS4=; b=vnnujf0ACY31xJA6dWzTLjkRE8U6IWjAxFm3ElQZgEBPfetWJCJuNeLTFB7ilrFu2g HUJ7q3eNx2GmZlYu618mTz3LXyACaRiYc4RZgmXAPm9D6/XLx+6UrXk+UZyXvxtzna1K Yew0JUeiNOd6e3PQQn/+g0EPRSjRWobby45HPBQZRkHaylkhfjRxD2FNoImj9hML6Ckt uGTi241Qbx7W8J0/V7L6hpKGW4WYF3PKv0utUH5oqVMJqQYds+9/GJ8DaL6cBeJ3Beqg lV8HsWPZ48lKfW4iKmOn2naQPjX9rYXXzmA+IQ77U7LWdxoh18dtHiLfO8G0g2Gifqzs cUag== X-Gm-Message-State: AJIora8teHV8RoXZHvJkZ0xUbVat6hJhF7oPYOoMLb7zcA5pwNgtFfEY m14frTP69l5JqyPFYNaLLWoDfhu8I+w= X-Google-Smtp-Source: AGRyM1tmrIjbcHM7OO+2kWIz6tviPfGhBRUOerePAxnT18qTKZVM7YPdxuminTXtlFpgr99IVafOYQ== X-Received: by 2002:a5d:6e8d:0:b0:21d:7adc:7102 with SMTP id k13-20020a5d6e8d000000b0021d7adc7102mr17502811wrz.9.1657557531353; Mon, 11 Jul 2022 09:38:51 -0700 (PDT) Received: from ?IPv6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id l19-20020a05600c1d1300b003976fbfbf00sm6980742wms.30.2022.07.11.09.38.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jul 2022 09:38:50 -0700 (PDT) Subject: Re: [PATCH 19/25] Don't resume new threads if scheduler-locking is in effect To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20220620225419.382221-1-pedro@palves.net> <20220620225419.382221-20-pedro@palves.net> <83a6a6l1fk.fsf@gnu.org> <72ce23b7-6e3c-b867-6d96-9df93fba5cfb@palves.net> <83mtdfzma7.fsf@gnu.org> <83h73nzk59.fsf@gnu.org> From: Pedro Alves Message-ID: <891ff735-3153-787e-cd6c-621180bf341b@palves.net> Date: Mon, 11 Jul 2022 17:38:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <83h73nzk59.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 16:38:55 -0000 On 2022-07-11 5:30 p.m., Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Mon, 11 Jul 2022 17:09:13 +0100 >> >>> That's fine, but I don't see how it implies anything for the NEWS >>> entry. Besides, the m,annual has context that NEWS not necessarily does. >> >> You had said "Same here, " for the manual part, and I was explaining that >> for the manual it makes sense to use "the", and that I just copied it over >> to NEWS. > > The remark about the manual was a general one. > >> --- c/gdb/NEWS >> +++ w/gdb/NEWS >> @@ -3,6 +3,13 @@ >> >> *** Changes since GDB 12 >> >> +* Scheduler-locking and new threads >> + >> + When scheduler-locking is in effect, only the current thread may run >> + when the inferior is resumed. However, previously, new threads >> + created by the resumed thread would still be able to run free. Now, >> + they are held stopped. > > This is okay. > >> diff --git c/gdb/doc/gdb.texinfo w/gdb/doc/gdb.texinfo >> index 7a4e337d15b..fc297218696 100644 >> --- c/gdb/doc/gdb.texinfo >> +++ w/gdb/doc/gdb.texinfo >> @@ -6953,6 +6953,9 @@ current thread away from the thread that you are debugging. The >> @code{replay} mode behaves like @code{off} in record mode and like >> @code{on} in replay mode. >> >> +When scheduler-locking is in effect, new threads created by the >> +resumed thread are held stopped. > > Here, I'd add this new info where the manual describes the feature > itself: > > @item set scheduler-locking @var{mode} > @cindex scheduler locking mode > @cindex lock scheduler > Set the scheduler locking mode. It applies to normal execution, > record mode, and replay mode. If it is @code{off}, then there is no > locking and any thread may run at any time. If @code{on}, then only > the current thread may run when the inferior is resumed; even threads > created by the resumed thread are held stopped. ^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > And now I wonder what happens when scheduler-locking is set to 'step': > are new threads created by the resumed thread held stopped as in the > ON case? > Yes, they are. That's why I put the new sentence at the end and not connected to "on", and said "is in effect", not "on". I.e., when the scheduler is actually locked.