From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id F3C3D3858407 for ; Mon, 11 Jul 2022 16:31:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F3C3D3858407 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56200) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAwJX-0000yA-D3; Mon, 11 Jul 2022 12:31:15 -0400 Received: from [87.69.77.57] (port=2168 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAwJS-0005mX-CU; Mon, 11 Jul 2022 12:31:11 -0400 Date: Mon, 11 Jul 2022 19:30:58 +0300 Message-Id: <83h73nzk59.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: (message from Pedro Alves on Mon, 11 Jul 2022 17:09:13 +0100) Subject: Re: [PATCH 19/25] Don't resume new threads if scheduler-locking is in effect 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> X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, 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:31:17 -0000 > 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?