On 22/12/2017 09:48, Mark Geisert wrote:
I'd still like to get a vote of acceptance for what I've called the
"courtesy" code in cygthread.cc, cygthread::name method. The method is
called with a Windows tid and that tid is looked up in the table of
cygthreads. If found, you immediately have the thread's name. I added
code on the failure path for the case where tid represents a pthread.
If it does, the pthread's name is retrieved into the result buffer.
This would be useful in straces of any application whose pthreads issue
Cygwin syscalls: It means the strace log has messages referring to
pthreads by their names and not by "unknown 0x###" as at present. It
was a help while debugging my "aio library built in userspace using
pthreads" that shall never be mentioned again ;-). But somebody else
coding or debugging their own multi-threaded app will run into this need
eventually.
Yeah, there's definitely a piece missing if pthread names aren't being
reported correctly in strace output.
I'd suggest it might be a bit cleaner to have a utility function used by
strace::vsprntf() to get the thread name, which tries cygthread::name()
or pthread_getname_np(), rather than having cygthread::name() be the
only part of cygthread which knows about pthreads...
Other uses of cygthread::name() need inspecting to see if they need to
change or not. Given [1], I think CW_GETTHREADNAME should stay as it is.
[1] https://cygwin.com/ml/cygwin/2009-05/msg00263.html
