How to enumerate stopped threads in C++ API?

Hi,

I am working on a custom debugger on Linux and I am using LLDB C++ API for that. So far, from the functionality point of view the life is good, but I am running into severe performance issue.

The problem is that the target application has literally hundreds of threads, and when the target process stops, I need to identify all the threads that have non-trivial stop reason. So, I am doing something like that:

// Loop over threads
int numThreads = m_Process.GetNumThreads();
for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
{
// Inspect the thread state
sbThread = m_Process.GetThreadAtIndex(threadIndex);
stopReason = sbThread.GetStopReason();

Well, this loop turns out to be a bottleneck.

So, is there any way to find all the stopped threads without iterating over the whole world?

Thanks,
Eugene

I'm surprised that this turns out to be a bottleneck. All the work to create the threads should have been done when you stopped, so this should just be running over a vector that already exists and pulling a field out. Can you profile this and see what is actually slow?

Jim

Each call into the lldb::SB* API will take a target lock and possible a process read/write lock.

We do have a SBThreadCollection class that we can use. Feel free to add an API like this to SBProcess:

class SBProcess
{
    SBThreadCollection GetThreads();
};

class SBThreadCollection
{
    SBThreadCollection GetThreadsWithStopReasons();
};

The current API on process SBProcess::GetNumThreads() and SBProcess::GetThreadAtIndex() might have issues if you are doing things like evaluating an expression on another thread where you might request the number of threads and get 10, but then an expression runs on another thread and there are now maybe 8 or 12 threads, and then you call SBProcess::GetThreadAtIndex() and it might return you results that are different that what you wanted. If we return all threads at once, we won't run into this issue. Then you can have SBThreadCollection add a new methods to return a new list for all threads with stop reasons.

That being said, hundreds of threads should not cause a huge bottleneck for single stop, but if you doing it many many many times it could be.

Greg Clayton

Thanks a lot!
We’ll try to profile what is going on, I’ll let you know if we find something.
Skipping locks if possible is always nice. I’ll look into getting collection approach.

Eugene