TIL another awful thing about Linux procfs behavior; top-level /proc only reports processes (thread-groups) via getdents/readdir, but opening /proc/$tid where $tid is any thread id (not necessarily also a process id) succeeds.
-
Show this thread
-
Replying to @RichFelker
IIRC in earlier versions of Linux all tasks (processes, threads) were in /proc and when threads got moved (tasks without CLONE_VM?) the open behaviour was kept for backwards compatibility. At one point ps and top showed threads by default.
1 reply 1 retweet 0 likes -
Replying to @corkmork
Rich Felker Retweeted Rich Felker
Yes I'm aware. See the other branch of this thread. Also it's CLONE_THREAD; you can use CLONE_VM without CLONE_THREAD, e.g. as vfork.https://twitter.com/RichFelker/status/984465290489749504 …
Rich Felker added,
4 replies 0 retweets 0 likes -
Replying to @RichFelker
Oh that’s right. Early on they only had CLONE_VM and no concept of tid. I think that is why CLONE_THREAD got added, so that proc and procps could differentiate processes from threads. I remember in the 2.4.x days a period where ps showed all threads as processes. Linus relented
1 reply 0 retweets 1 like
Showing them in /proc was the least of the problems with this naive and bone-headed approach. Signal semantics, child process relationships, exec behavior, etc. were all wrong and could not be fixed just by emulating pthreads in userspace.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.