This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Single stepping and threads

>  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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]