| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1477.1 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Tue Feb 04 1997 04:27 | 24 |
| There is no way to get a list of threads without stopping them. That's
because the list of running threads is itself data that can change at any
time, and we can't read the list reliably without synchronization. The
ladebug debugger uses our libpthreaddebug.so debugging interfaces... but that
will suspend the process while traversing the list of threads.
The ps command knows nothing about user threads, only kernel (Mach) threads,
which don't have names, and have no real connection to the threads you create
using pthread_create(). Prior to Digital UNIX 4.0, each user thread had a
unique kernel thread -- though the kernel thread still had no concept of a
"name", and there was no easy way (even for us) to determine which kernel
thread mapped to which user thread. In 4.0, though, all the user threads
share a smaller number of kernel threads, dynamically. Using "ps" to show the
threads in a process is therefore very much like trying to use psrinfo to
show the processes on a system.
Although Pete has toyed with the idea of getting ps to use libpthreaddebug, I
don't seriously expect that to happen. (And I'm not entirely sure it would
really make sense.)
Supported object naming interfaces are planned for Steel. They may, however,
appear in PTmin.
/dave
|
| 1477.2 | Ok | TAEC::MARTIN | | Tue Feb 04 1997 08:08 | 3 |
| Thank you for your clarification.
Laurent
|
| 1477.3 | | QUARRY::petert | rigidly defined areas of doubt and uncertainty | Tue Feb 04 1997 10:17 | 6 |
| If you have to stop the process to get the list of threads, then I think
it would be a very bad idea to have ps use libpthreaddebug. Having ps
stop a process, even briefly, seems like something our customers would
complain about.
PeterT
|
| 1477.4 | That looks useful | EDSCLU::GARROD | IBM Interconnect Engineering | Wed Feb 05 1997 20:12 | 21 |
| re:
>For the moment i use this function:
>int
>pthread_attr_setname_np (pthread_attr_t *attr,
> char *name)
>{
> *((char**)attr+1)=name;
> return 0;
>}
I too would like to see some decent thread names rather than just
anonymous. It would help debugging.
A question for the threads developers. Would it cause a problem to put
this code in shipping code. It looks simple. Would it break anything.
Obviously if I did I wouldn't use the pthreads name. Or is this a big
NO NO?
Dave
|
| 1477.5 | | DCETHD::BUTENHOF | Dave Butenhof, DECthreads | Thu Feb 06 1997 07:45 | 35 |
| DECthreads has had names for all objects ever since the very beginning. The
original CMA interface lacked interfaces for naming only because we were
developing in a, shall we say, excessively forward-looking environment, and
got tied up worrying about what sort of string support we should have.
Digital was starting to get into multi-byte character strings, for example.
Should we support them? How? We wanted to be cross-platform, and the support
wasn't there. We weren't sure what "the right thing" was, so we did nothing.
Thus, names are still internal to DECthreads, and not accessible outside. The
focus of DECthreads has changed a lot over the years -- the original
uncertainty long since stopped being relevant. Of course, we should just pass
strings using standard C null-terminated byte array semantics. What else? But
we've had more important things to worry about. And there were still
technical issues -- should we support changing "live" objects? Should we only
support setting an attribute on creation?
I finally got stung into doing something by a major customer requirement,
very recently. Digital UNIX "PTmin" should have naming interfaces. I decided
to provide a name ATTRIBUTE for threads, because the thread may run before
pthread_create() returns, and having to wait and name the live object would
largely negate the value of having a name. However, all other objects
(mutexes, condition variables, and thread-specific data keys) are named only
AFTER creation, using new "setname_np" interfaces. (You can also set a "live"
thread's name, but that's probably not a good idea unless you do it within
the thread's start routine.)
Oh, and, by the way... I didn't mention this before because the author of the
note specifically said he was using the hack ONLY for private debugging
purposes. But, just in case anyone gets any ideas about "jumping the gun"...
Reaching into the (opaque) attributes object to TRASH an arbitrary offset
with the address of a name string is a program BUG, and will NOT be supported
in any fashion! It may very well break at any time in the future, in other
words, and it will NOT be our fault!
/dave
|
| 1477.6 | Just to reiterate... | WTFN::SCALES | Despair is appropriate and inevitable. | Thu Feb 06 1997 18:39 | 24 |
| .4> It looks simple.
It is simple: it's simply UNSUPPORTED.
.4> Would it break anything.
If the DECthreads team chose to alter the data structure which you are
molesting, your software and anything calling it would likely be broken. We
reserve the right to make changes of that sort; we will do it if we need to; and
we won't consider the impact on software which is doing things which it patently
should not be doing.
.4> Would it cause a problem to put this code in shipping code.
I wouldn't ship it if I were you. It's perfectly reasonable to engage in
hackery like this when you're trying to diagnose something. But, in terms of
shipping a supported product, one which is supposed to be maintained across
multiple versions of the OS, and which is shipped independently of the OS,
you're way out of line doing stuff like this, and you're likely to get very
little sympathy from us if you do (i.e., you will either be laughed at or
cursed, depending on how much grief it causes us and Digital).
Webb
|