> On Sep 2, 2015, at 1:06 PM, Greg Clayton via lldb-dev > <lldb-dev@lists.llvm.org> 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, it is quite easy to tell. User created threads could be ones > whose bottom stack frame is "thread_start" > > .... > frame #8: 0x00007fff9b47c41d libsystem_pthread.dylib thread_start + 13 > > Where OS created threads have their last frames in "start_wqthread" or > "_dispatch_mgr_thread": > > ... > frame #2: 0x00007fff9b47c40d libsystem_pthread.dylib start_wqthread + 13 > > or: > > ... > frame #2: 0x00007fff9c298a6a libdispatch.dylib _dispatch_mgr_thread + 52 > > > So it might be easy to add API to SBThread like: > > bool > SBThread::IsUserCreated(); > > Then we could teach the tests to filter out any threads that are not user > created?
I'm not sure on OS X this is a terribly useful distinction. There are lots of threads that are created to run user code through the dispatch library. They won't start with "thread_start" but I don't think most users would think of them as "not user threads..." Jim > > Greg > > >> On Sep 2, 2015, at 12:31 PM, Zachary Turner via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> 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 portability issue, I ported most of these tests >> over to std::threads, but there is still another issue with them. >> >> On Windows we can't assume anything about the number of threads in a >> program. For example, a single-threaded hello world program actually has 3 >> threads, 2 of which are reserved for use by the operating system. And the >> fact that there's 2 is just arbitrary, that might not remain the same >> between compiler versions, operating system versions, etc. And to make >> matters worse it might not even remain constant through the life of the >> program (the assumption just being that we cannot make any assumptions, >> since we don't control the threads). >> >> So I need to find a way to write these tests portably. >> >> Do all platforms have a way to assign a thread a name? Looking in >> Host/*/ThisThread.cpp, it seems: >> >> 1) Linux and MacOSX inferiors can use pthread_setname_np >> 2) FreeBSD inferiors can use pthread_set_name_np >> 3) Windows inferiors can raise a magic exception which the debugger is >> expected to recognize >> >> Based on this, it seems that one possible way to write these tests portably >> is to have the test inferiors assign names to the threads, and have the >> tests index the threads by name instead of by ordinal. >> >> Does anyone have any thoughts on this or other possible approaches? >> >> I really would like to avoid having different inferiors or different tests >> for all of this functionality, as it will be very easy to get out of sync. >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
