+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 <lldb-dev@lists.llvm.org> wrote: > 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. So we need to > not go crazy on thread naming conventions. The code has it, but I think the > limit on Linux and FreeBSD was something like 16 characters. > > On Wed, Sep 2, 2015 at 2:48 PM, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: >> >> >> > 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 > > > > > -- > -Todd > > _______________________________________________ > 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
