discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] debugging code for seeing what threads are create


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] debugging code for seeing what threads are created
Date: Tue, 20 Jul 2010 11:39:01 -0700
User-agent: Mutt/1.5.20 (2009-08-17)

On Tue, Jul 20, 2010 at 11:04:25AM +0100, Alex wrote:
> >
> > Please read the ps man page and pick options that will show you detail
> > information on all the threads.
> >
> 
> Reread the man page but from what i gather ps isn't capable of displaying
> what I'm looking for, which is a name for the thread, or something to tell
> me which block it belongs to.

Right.  They don't have names.

You might want to try oprofile.  It'll give you an idea which routines
are burning up the most time, but it won't tie it back to which thread.

You might be able to get something useful by using getrusage(2),
specifying RUSAGE_THREAD.  Off the top of my head, for the
thread-per-block scheduler, I suggest putting the call into
gr_block_executor::~gr_block_executor, as the last thing.  
It'll get called just before the thread is deleted.

In the destructor, the name of block is available as
d_block->name().  You can also use std::cout << d_block



> > Not exactly sure what you're looking for, but when using the
> > thread-per-block scheduler, there will be one thread created per
> > block.
> >
> 
> I am aware of that and I'm looking for some sort of output to tell me
> something along the lines of when a block starts, what it's doing and
> when it stops.
> 
> Also when I run in single-thread scheduler I have a waveform that runs
> with 3 threads and one with 2 threads and I would like to know what they
> are

When using the single-threaded-scheduler, if the flow graph consists
of more than 1 distinct subgraph, each subgraph will get its own
thread.  (Most often you'll see this with a transceiver, where the Tx
and Rx are implemented by separate hier blocks that are contained by
the single top_block, but aren't otherwise connected to each other.)

> Thank you

You're welcome!

Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]