Am Tue, 22 Feb 2022 17:53:12 -0600 schrieb "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>: > How do you figure? I admit that I am struggling with understanding where exit codes come from in the non-usual cases. During my taskstats tests, I played with writing a multithreaded application that does call pthread_exit() in the main thread (pid==tgid), for example. I slowly had to learn just how messy this can be … Is it clearly defined what the exitcode of a task as part of a process is/should/can mean, as opposed to the process as a whole? > For single-threaded processes ac_exitcode would always be reasonable, > and be what userspace passed to exit(3). Yes. That is the one case where we all know what we are dealing with;-) > For multi-threaded processes ac_exitcode before my change was set to > some completely arbitrary value for the thread whose tgid == tid. Isn't the only place where it really makes sense to set the exitcode when the last task of the process exits? I guess that was the intention of the earlier code — with the same wrong assumption that I fell victim to for quite some time: That the group leader (first task, tgid == pid) always exits last. I do not know in which cases group member threads have meaningful exit codes different from the last one (which is the one returned for the process in whole … ?). I'd love to see the exact reasoning on how multithreading got mapped into kernel tasks which used to track only single-threaded processes before. > With my change the value returned > is at least well defined. But defined to what? > Now maybe it would have been better to flag the bug fix with a version > number. Unfortunately I did not even realize taskstats had a version > number. I just know the code made no sense. Well, fixing a bug that has been there from the beginning (of adding multithreading, at least) is a significant change that one might want to know about. And I do think that it fits to thouroughly fix these issues that relate to identifying threads and processes (the shameless plug of my taskstats patch that I'm working on since 2018, and only got right in 2022, finally — I hope), while at that. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
