[lldb-dev] Portable tests that create threads

[Pavel Labath via lldb-dev]

+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 at 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 at lists.llvm.org> wrote:
>>
>>
>> > On Sep 2, 2015, at 1:06 PM, Greg Clayton via lldb-dev
>> > <lldb-dev at 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 at 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 at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> -Todd
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>