On Mon, Oct 30, 2017 at 04:06:15PM -0700, Kevin Buettner wrote:
> This patch adds a new member named "pthread_id" to the gomp_thread
> struct. It is initialized in team.c.
That part is reasonable, though it is unclear how the debugger will
query it (through OMPD, or through hardcoded name lookup of the struct and
field in libgomp's debug info, something else). But the field certainly
has to be guarded by #ifdef LIBGOMP_USE_PTHREADS, otherwise it will break
NVPTX offloading or any other pthread-less libgomp ports.
Another question is exact placement of the field, struct gomp_thread
vs. struct gomp_team_state etc. Maybe it is ok, as the pthread_id is
the same once the thread is created, doesn't change when we create more
levels.
> It also adds a field named "parent" which is initialized to the thread
> which created the thread in question. For non-nested parallel
> regions, this is always the master thread.
What do you need it for and why isn't the current way of querying
parent (see e.g. omp_get_ancestor_thread_num or omp_get_team_size)
sufficient for the debugger? Even if gomp_team_state doesn't contain
pthread_id, perhaps it would be more space and performance efficient
to store some pointer into struct gomp_team, gomp_team_state/gomp_thread
structs are in TLS which should be kept as small as possible.
Why do you care about which thread called pthread_create, rather than
what actually owns it right now (is the master thread)?
Jakub
