@jaketesler - Hi, and thanks in advance. Many thanks for offering to be "tagged"!

This seems straight forward - and I hope complete (docs updated). (also thanks to@ncoghlan iirc who pointed at thread_self() - the "kernel" routine versus the posix thread *_self routine!

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

-1

As you already said, pthread_self does not return the TID,https://linux.die.net/man/3/pthread_self

The thread ID returned by pthread_self() is not the same thing as the kernel thread ID returned by a call to gettid(2).

I'd rather not provide the feature at all than to provide an implementation that does not match with other implementations.

And I did not use pthread_self() - I used thread_self() - also a routine that has been around for years.

A short example - with also the verification from "ps" that the value returned by thread_self is - indeed - the KERNEL tid and not the POSIX_tid.

root@x066:[/data/prj/aixtools/tests/posix]./thread_selfthread_self: pid:7602402 tid:12779547 ptid:1[1] + Stopped (SIGTSTP)        ./thread_selfroot@x066:[/data/prj/aixtools/tests/posix]ps -p 7602402 -mo THREAD    USER     PID    PPID       TID ST  CP PRI SC    WCHAN        F     TT BND COMMAND    root 7602402 7209084         - T    0  60  1 f1000a040034adb0   200011  pts/0   - ./thread_self       -       -       -  12779547 T    0  60  1 f1000a040034adb0   410400      -   - -root@x066:[/data/prj/aixtools/tests/posix]cat thread_self.c#include <pthread.h>#include <sys/thread.h>#include <stdio.h>main(){        pid_t pid;        tid_t tid;        pthread_t ptid;        pid = getpid();        tid = thread_self();        ptid = pthread_self();        fprintf(stderr,"thread_self: pid:%d tid:%d ptid:%d\n", pid, tid, ptid);        sleep(300);     /* give time to run ps -mo THREAD */}

So, not understanding the GIT process - you requested a change - but I do not see anything to change. Other than perhaps my comment where I thanked 'someone' for pointing out the issue BEFORE I submitted anything.

Regards,
Michael

This may provide some clarity –https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.basetrf2/thread_self.htm

@aixtools@encukou has cleared out the review that was based on misreading the update. It's likely worth adding a clarifying comment to the new AIX code, referencing the link that@jaketesler's provided, as I doubt@tiran will be the only reader to ever miss the fact that there's no leading "p" on the function name.

Do you have any thoughts on how we might be able to properly test this change? The existing native thread ID code doesn't appear to have any obvious tests either, so I wouldn't consider that a merge blocker, but it would still be nice if we could add that missing test coverage while folks have eyes on the code anyway.

Thanks for making the requested changes!

@asvetlov: please review the changes made to this pull request.

Yes, it looks a bit like a recommendation. FWIW, I recently had this conversation with a highly advanced git user, and his opinion was to merge master into the PR for all projects that squash merges, because the alternative is too complex for PRs that are open for a long time.

I agree with him. While I use rebase often (especially for branches before sending pull request), it requires high git knowledge. Additionally, it requires-f option whengit push. It is dangerous for new git users too.
I think "git rebase" shouldn't be recommended for new users.

I am thinking the "rebase" - read "merge" should be written up in the devguide. I tried reading up on it yesterday and this morning - and my head hurts - how to make it simple.

What I think has been vital for me was seeing how to merge from "upstream". I thought I had to maintain my fork at 100% - so I had a separate directory for "maintaining" the fork and then did all my cloneing, merge, pull, etc. from my fork rather than from "upstream".

I suppose when in a team using git - rather than "solo" (aka wannabe 'member') getting advice and direction in how to use git effectively is more efficient than googling through multiple opinions written up as tutorials.

:) so happy this "merge" went smoothly.

I sent pull request to stop recommend "rebase":python/devguide#496

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again.

Thanks for making the requested changes!

@asvetlov: please review the changes made to this pull request.

Thanks@aixtools for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

GH-14067 is a backport of this pull request to the3.8 branch.