From: "Mark Kettenis" <mark.kettenis@xs4all.nl>
To: gdb@sourceware.org
Subject: Re: Single stepping and threads
Date: Wed, 29 Nov 2006 12:41:00 -0000 [thread overview]
Message-ID: <6734.193.137.208.250.1164804049.squirrel@webmail.xs4all.nl> (raw)
In-Reply-To: <20061129052942.GA16029@nevyn.them.org>
> Ulrich's message earlier reminded me of something I've been meaning to
> discuss for a while. This isn't specific to software single stepping,
> but to single step in general for threaded programs.
>
> We have a knob "set scheduler-locking". It offers three values:
>
> Set mode for locking scheduler during execution.
> off == no locking (threads may preempt at any time)
> on == full locking (no thread except the current thread may run)
> step == scheduler locked during every single-step operation.
> In this mode, no other thread may run during a step command.
> Other threads may run while stepping over a function call
> ('next').
>
> The default is "off". Should it be "step" instead? The example I used
> to use whenever someone asked me about this was single stepping through
> something like a barrier or mutex; if other threads don't run, you
> won't advance, because no other thread will have a chance to release
> the lock. That much is true. But it seems like a reasonable thing to
> document and reference "set scheduler-locking". And having threads
> run during single stepping has surprised a lot of users who've asked
> me about the current behavior.
>
> What do you all think?
Are you talking about stepi or step?
For step we should be very careful, since on some platforms the dynamic
linker may play games with locks and we risk a deadlock if we don't let
the other threads run.
next prev parent reply other threads:[~2006-11-29 12:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 5:29 Daniel Jacobowitz
2006-11-29 5:58 ` Joel Brobecker
2006-11-29 13:25 ` Daniel Jacobowitz
2006-11-29 16:38 ` Joel Brobecker
2006-11-30 13:54 ` Daniel Jacobowitz
2006-11-30 23:36 ` Michael Snyder
2006-11-30 23:54 ` Joel Brobecker
2006-12-01 1:02 ` Daniel Jacobowitz
2006-12-01 22:43 ` Michael Snyder
2006-12-02 16:27 ` Rob Quill
2006-12-02 16:33 ` Daniel Jacobowitz
2006-12-02 16:36 ` Joel Brobecker
2006-12-04 19:50 ` Michael Snyder
2006-11-30 8:44 ` Robert Dewar
2006-11-30 23:32 ` Michael Snyder
2006-11-30 23:26 ` Michael Snyder
2006-11-30 23:31 ` Joel Brobecker
2006-11-29 12:41 ` Mark Kettenis [this message]
2006-11-29 13:36 ` Daniel Jacobowitz
2006-11-30 23:38 ` Michael Snyder
2006-11-30 23:22 ` Michael Snyder
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=6734.193.137.208.250.1164804049.squirrel@webmail.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=gdb@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