Hi John, I appreciate you taking the time to comment. I agree with your
assessments and wanted to comment on a few points.
> C'mon. The tools re-use thread IDs because that is the easiest
> and most efficient way to track the running threads.
> If no re-use, then the next easiest way is to increment forever.
> Then the threadID cannot be an 'unsigned short', and there must be
> an adaptive hash table (or other non-trivial lookup mechanism)
> from threadID to internal thread structure, and the hash table
> must allow frequent deletions.
To clarify, I am not suggesting a change to make every thread hash to a
unique ID.
I was asking if there were any best-known-methods for detecting a new
thread in the Valgrind scheduler. For example, it looks like tools such as
Callgrind, rely on calling VG_(get_running_tid)() every basic block to
detect different threads. Using this method can produce misleading
information by conflating metadata from different threads.
Notably, Linux approaches PID generation by incrementing until the max ID
is reached, and then wrapping around and reusing any available IDs.
Although I don't know the internals of how the kernel achieves this, this
can be naively tracked with a 8KB bit vector for a 16-bit thread ID, .
I'm unaware of how Valgrind currently tracks thread IDs.
> Modify the source to suit yourself. You will see how
> un-worthwhile the modifications are for the existing use cases.
Again, I'm not contending for Valgrind internal changes. I would contend,
however, that being able to reliably detect when a thread starts/stops
within instrumented code is valuable.
I've seen the track_{start,stop}_client_code callbacks suggested, but I've
also seen that VG_(get_running_tid)() is supposed to be more reliable.
e.g.
*http://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg03441.html
<http://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg03441.html>
*
Thank you again,
Mike
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
