threads and target-function-calls

threads and target-function-calls

[Michael Snyder]

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?

Michael

Re: threads and target-function-calls

[Daniel Jacobowitz]

On Tue, Jan 07, 2003 at 05:00:25PM -0800, Michael Snyder 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?

Eeeeek!  I think I agree with you here; that's the logical behavior. 
It never occured to me to try.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: threads and target-function-calls

[Dan Mosedale]

Daniel Jacobowitz wrote:

>On Tue, Jan 07, 2003 at 05:00:25PM -0800, Michael Snyder 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?
>>    
>>
>
>Eeeeek!  I think I agree with you here; that's the logical behavior. 
>It never occured to me to try.
>
What happens if the target function wants to interact with another 
thread?  e.g. wait on a mutex being held by another thread?

Dan

Re: threads and target-function-calls

[Daniel Jacobowitz]

On Tue, Jan 07, 2003 at 06:49:27PM -0800, Dan Mosedale wrote:
> Daniel Jacobowitz wrote:
> 
> >On Tue, Jan 07, 2003 at 05:00:25PM -0800, Michael Snyder 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?
> >>   
> >>
> >
> >Eeeeek!  I think I agree with you here; that's the logical behavior. 
> >It never occured to me to try.
> >
> What happens if the target function wants to interact with another 
> thread?  e.g. wait on a mutex being held by another thread?

It'll deadlock; the user will Control-C; then he can either use
"return" to cancel the call, or free the mutex himself, or whatever.
Letting all threads just resume what they were doing doesn't seem to
make sense in general...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: threads and target-function-calls

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Tue, Jan 07, 2003 at 05:00:25PM -0800, Michael Snyder 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?
> 
> Eeeeek!  I think I agree with you here; that's the logical behavior.
> It never occured to me to try.

I just happened to have "debug lin-lwp" turned on.

Perhaps we need to think about what "target function call"
actually means in the presence of threads that can interact
with each other.

Re: threads and target-function-calls

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 04:48:35PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Tue, Jan 07, 2003 at 05:00:25PM -0800, Michael Snyder 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?
> > 
> > Eeeeek!  I think I agree with you here; that's the logical behavior.
> > It never occured to me to try.
> 
> I just happened to have "debug lin-lwp" turned on.
> 
> Perhaps we need to think about what "target function call"
> actually means in the presence of threads that can interact
> with each other.

Yeah.  My biggest concern is an interface one.  What the heck _should_
happen?  And how do we present it to the user?

[On an interesting side note, another debugger developer mentioned to
me that their product supports conditional breakpoints by inserting
code into the inferior.  That'd be nice to do some day... but we don't
really have the architecture for it right now...]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: threads and target-function-calls

[Andrew Cagney]

> 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

Andrew

Re: threads and target-function-calls

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 11:17:45AM -0500, 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

Oh, lord.  That's going to take some serious fixing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: threads and target-function-calls

[Michael Snyder]

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.

Re: threads and target-function-calls

[Michael Snyder]

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?

Re: threads and target-function-calls

[Andrew Cagney]

> 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.  Or even things like:

	(gdb) print foo()
	[new thread xyx]
	Thread xyz hit breakpoint 2 in foo()
	(gdb) print bar()

(there was talk of trying to only allow one thread to run).

Andrew

Re: threads and target-function-calls

[Michael Snyder]

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.