| Summary: | Add pid_t pthread_gettid_np(pthread_t *thr). | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Nicholas Miell <nmiell> |
| Component: | nptl | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | enhancement | CC: | bugdal, drepper.fsp, fweimer, neleai |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| See Also: | https://sourceware.org/bugzilla/show_bug.cgi?id=27880 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
Converting a TID to a pthread_t is highly non-trivial; there's no direct mapping possible. The best way I can think of is using one of the pthread-implementation-reserved signals to signal the TID and request it to call pthread_self and pass back the result. Another option that would remove the need for the difficult-to-provide interface just for the sake of having an inverse function would be to forget pthread_gettid_np and just expose gettid (if it's not already exposed). I would say best practices would have a thread arranging for its own receipt of signals rather than having other threads set it up... Anyway, shouldn't this report/request be marked as "enhancement" importance rather than "normal" or even "minor"? It doesn't seem like a bug. |
fcntl(fd, F_SETOWN_EX, &((struct f_owner_ex) {F_OWNER_TID, tid})) needs some way of getting a thread's TID, and manually calling the gettid() syscall yourself is ugly. There should probably be a way of converting a TID to a pthread_t, too.