From: Pedro Alves <pedro@palves.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 19/25] Don't resume new threads if scheduler-locking is in effect
Date: Mon, 11 Jul 2022 17:38:48 +0100 [thread overview]
Message-ID: <891ff735-3153-787e-cd6c-621180bf341b@palves.net> (raw)
In-Reply-To: <83h73nzk59.fsf@gnu.org>
On 2022-07-11 5:30 p.m., Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>> 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.
next prev parent reply other threads:[~2022-07-11 16:38 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 22:53 [PATCH 00/25] Step over thread clone and thread exit Pedro Alves
2022-06-20 22:53 ` [PATCH 01/25] Don't use pthread_mutex_t in gdb.base/step-over-clone.c Pedro Alves
2022-07-13 21:35 ` Pedro Alves
2022-06-20 22:53 ` [PATCH 02/25] displaced step: pass down target_waitstatus instead of gdb_signal Pedro Alves
2022-06-20 22:53 ` [PATCH 03/25] linux-nat: introduce pending_status_str Pedro Alves
2022-06-20 22:53 ` [PATCH 04/25] Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED Pedro Alves
2022-06-20 22:53 ` [PATCH 05/25] Support clone events in the remote protocol Pedro Alves
2022-06-20 22:54 ` [PATCH 06/25] Thread options & clone events (core + remote) Pedro Alves
2022-06-20 22:54 ` [PATCH 07/25] Thread options & clone events (native Linux) Pedro Alves
2022-06-20 22:54 ` [PATCH 08/25] Thread options & clone events (Linux GDBserver) Pedro Alves
2022-06-20 22:54 ` [PATCH 09/25] gdbserver: Hide and don't detach pending clone children Pedro Alves
2022-06-20 22:54 ` [PATCH 10/25] Remove gdb/19675 kfails (displaced stepping + clone) Pedro Alves
2022-06-20 22:54 ` [PATCH 11/25] Add test for stepping over clone syscall Pedro Alves
2022-06-20 22:54 ` [PATCH 12/25] all-stop/synchronous RSP support thread-exit events Pedro Alves
2022-06-20 22:54 ` [PATCH 13/25] Introduce GDB_TO_EXIT thread option, fix step-over-thread-exit Pedro Alves
2022-06-20 22:54 ` [PATCH 14/25] Implement GDB_TO_EXIT support for Linux GDBserver Pedro Alves
2022-06-20 22:54 ` [PATCH 15/25] Implement GDB_TO_EXIT support for native Linux Pedro Alves
2022-06-20 22:54 ` [PATCH 16/25] gdb: clear step over information on thread exit (PR gdb/27338) Pedro Alves
2022-06-20 22:54 ` [PATCH 17/25] stop_all_threads: (re-)enable async before waiting for stops Pedro Alves
2022-06-20 22:54 ` [PATCH 18/25] gdbserver: Queue no-resumed event after thread exit Pedro Alves
2022-06-20 22:54 ` [PATCH 19/25] Don't resume new threads if scheduler-locking is in effect Pedro Alves
2022-06-21 11:07 ` Eli Zaretskii
2022-07-11 14:20 ` Pedro Alves
2022-07-11 15:44 ` Eli Zaretskii
2022-07-11 16:09 ` Pedro Alves
2022-07-11 16:30 ` Eli Zaretskii
2022-07-11 16:38 ` Pedro Alves [this message]
2022-07-11 17:00 ` Eli Zaretskii
2022-07-11 17:48 ` Pedro Alves
2022-07-11 17:50 ` Eli Zaretskii
2022-07-11 18:18 ` Pedro Alves
2022-07-11 18:29 ` Eli Zaretskii
2022-07-11 19:39 ` Pedro Alves
2022-07-12 16:08 ` Eli Zaretskii
2022-07-12 17:14 ` Pedro Alves
2022-06-20 22:54 ` [PATCH 20/25] Tighten gdb.threads/no-unwaited-for-left.exp regexps Pedro Alves
2022-07-13 21:32 ` Pedro Alves
2022-06-20 22:54 ` [PATCH 21/25] Report thread exit event for leader if reporting thread exit events Pedro Alves
2022-06-20 22:54 ` [PATCH 22/25] Ignore failure to read PC when resuming Pedro Alves
2022-06-20 22:54 ` [PATCH 23/25] gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macro Pedro Alves
2022-06-20 22:54 ` [PATCH 24/25] Testcases for stepping over thread exit syscall (PR gdb/27338) Pedro Alves
2022-06-20 22:54 ` [PATCH 25/25] Document remote clone events, and QThreadOptions packet Pedro Alves
2022-06-21 12:07 ` Eli Zaretskii
2022-07-11 15:19 ` Pedro Alves
2022-07-11 16:09 ` Eli Zaretskii
2022-07-11 16:54 ` Pedro Alves
2022-07-11 17:02 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=891ff735-3153-787e-cd6c-621180bf341b@palves.net \
--to=pedro@palves.net \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).