[lldb-dev] Portable tests that create threads

[Todd Fiala via lldb-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150902/b4621da9/attachment.html>