Re: [PATCH] cygwin_internal methods to get/set thread name

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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.  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.  

(*) 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...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature