[PATCH] cygwin_internal methods to get/set thread name

Mark Geisert mark@maxrnd.com
Fri Dec 22 09:48:00 GMT 2017

On Thu, 21 Dec 2017, Corinna Vinschen wrote:
> On Dec 21 00:29, Mark Geisert wrote:
>> On Wed, 20 Dec 2017, Corinna Vinschen wrote:
>>> Hi Mark,
>>> A lot to discuss here.
>> Yes, but first let me say I'd call these "speculative" patches, things I
>> found necessary during aio library development.  I had an incorrect mental
>> picture of the Cygwin DLL: I was treating it as just a user-space DLL where,
>> for an add-on library, one was free to use Cygwin constructs or pthread
>> constructs, or even Win32 constructs for that matter.
>> I've now updated that mental picture of the Cygwin DLL to treat it as a
>> kernel, where one can only use constructs provided by Cygwin.  So, in the
>> aio library there will be cygthreads only and no pthreads or Win32 threads.
>> (So I should also separately update the gmon profiler to use a cygthread
>> rather than a Win32 thread ;-)).
> You're right that Cygwin is treated as kernel because it plays this
> role (combined with libc, libm, etc) for all the rest of Cygwin libs
> and executables.
> But I'm not sure what you mean by "aio library" here.  aio functionality
> should be part of Cygwin itself.  As soon as you implement another
> library linking against the Cygwin DLL, you're "user space" and thus you
> can only use POSIX calls.

I fear I may have confused you by discussing what I *had* implemented, but 
have now discarded in order to use a new approach.  The new approach (aio 
within Cygwin DLL, using cygthreads but only if necessary) I do agree with 
and will implement towards.  But what I had working already, previously, 
was a separate aio library built on top of Cygwin that I linked with my 
test app.  That library operated just as you surmised above: only used 
POSIX calls, used pthreads, only used cygwin_internal() to get at 
underlying fds.  I agree that that first approach, though working, is a 
non-starter for a robust Cygwin aio facility.

>                            The cygwin_internal() call is a very narrow
> exception, which basically should only be used to access Cygwin
> internals by applications which know what they are doing.  That's almost
> exclusively the stuff in the winsup/utils dir.  Given that cygthreads
> are not exported from the Cygwin DLL, you would not be able to use them(*)
> So as I understood it, aio stuff should be implemented inside the
> "kernel", the Cygwin DLL, using internal classes, methods and functions,
> exporting aio POSIX calls to user space.  Thus it's not clear to me what
> you mean by "aio library" at the moment.

I just meant the aio_* and lio_* functions as a group.  Wasn't using 
"library" literally, though my first implementation was organized as a 
linkable library.  "Facility" would be a better word than library.

> (*) Actually, I think you won't need threads at all if you use Windows
>    completion routines, but you know that already :}


>> So these patches reflect the earlier mental picture.  Maybe none of the code
>> makes sense in an accurate mental picture.  I wanted to at least air the
>> code to see if some use might be made of it before discarding it.
> I don't see a need for such calls unless they are used by very specific
> scenarios, like GDB or strace.
>> [...]
>> I was using strace and getting annoyed with it displaying "unknown thread
>> 0x###" for my aio threads.  At that point they were pthreads and not
>> cygthreads.  So that was the impetus for the name-getting additions.
>> Name-setting, that's another story.  I thought that perhaps a debugging app
>> might want to tag threads of a subject process with names if they don't
>> already have names.  But I concede there is no such app at present.
> Given that you'd have to call cygwin_internal as well as
> pthread_setname_np in the context of the traced process, there's not
> much difference...

Yes, I see now what you mean.  I wasn't looking from far enough away.

Welp, it seems all the patch content relating to cygwin_internal() 
should go away.

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.
Thanks for reading,


More information about the Cygwin-patches mailing list