+1 for the naming idea. It sounds like the a more reliable solution
than crawling backtraces to me.
pl
On 3 September 2015 at 06:32, Todd Fiala via lldb-dev
wrote:
> I think the thread naming is a reasonable way to go.
>
>> 1) Linux and MacOSX inferiors can use pthread_setname_np
>> 2) FreeBSD i
I think the thread naming is a reasonable way to go.
> 1) Linux and MacOSX inferiors can use pthread_setname_np
> 2) FreeBSD inferiors can use pthread_set_name_np
IIRC Linux and FreeBSD both are limited to a very short thread name, much
shorter than OS X and, if I'm not mistaken, Windows as well.
> On Sep 2, 2015, at 1:06 PM, Greg Clayton via lldb-dev
> wrote:
>
> One idea is add the ability to discover which of any of the current threads
> are or are not user created. This might help us.
>
> On MacOSX, the main thread would always be considered user created, and any
> other thread,
I don't think that's a good plan. It's the implementation of std::thread
that created the thread pool. It's quite possible that it then
re-purposing thread pool threads as user threads. This gets into
implementation details that we'd have to figure out and which could change.
Even with the equi
That might work, on Windows I think we could identify this by looking
for ntdll.dll!TppWorkerThread() in the stack frame. This might not be
exactly the same across OS versions, but we could handle all cases as new
ones are discovered.
We would have to make sure that all developers are educated on
One idea is add the ability to discover which of any of the current threads are
or are not user created. This might help us.
On MacOSX, the main thread would always be considered user created, and any
other thread, it is quite easy to tell. User created threads could be ones
whose bottom stack
Historically the pattern for tests that need to test situations involving
threads has been to write the tests using pthreads, and then a common
pattern on the python side of the test is to assert that the actual number
of threads equals the expected number of threads.
To deal with the pthread port
