Re: threads and target-function-calls

[Michael Snyder <msnyder at redhat dot com>]

Andrew Cagney wrote:
> 
> > Michael Snyder wrote:
> >
> >>
> >> Andrew Cagney wrote:
> >
> >> >
> >
> >> > > Hey folks,
> >> > >
> >> > > Did you know that (at least on x86 linux), if you have a multi-thread
> >> > > program and you execute a target function call, all the threads get to
> >> > > run?  Doesn't that seem like a bad thing?  Wouldn't we really rather
> >> > > only run the thread that is executing the target function call?
> >
> >> >
> >> > Ha!  That's just the start.  Doing nested inferior function calls on
> >> > alternative threads scrables the dummy frame cache:
> >> > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=468
> >
> >>
> >> But... that's just sick.   ;-(
> >> Wait -- you can't do that.  It isn't meaningful to change threads
> >> and then continue/whatever.  It assumes gdb has more control over
> >> scheduling than it actually has.
> >
> >
> > Oh, I think I misunderstood.  You have in mind this:
> >       (gdb) print foo()
> >       [switching thread to xyz]
> >       Breakpoint 2 in foo ()
> >       (gdb) print bar()
> >
> > not this:
> >       (gdb) print foo ()
> >       breakpoint 2 in foo()
> >       (gdb) thread xyz
> >       (gdb) print bar()
> >
> > right?
> 
> Either.  

OK, well, the second should not be a concern, because
prepare_to_proceed is supposed to switch us back to the
event thread before we resume.