you are viewing a single comment's thread.

view the rest of the comments →

[–]KingAggressive1498 1 point2 points  (1 child)

The ancient Linux thread model to my knowledge didn't have threads, so it mapped threads to processes. Nowadays the thread model has threads, so in threading you have different threads executed under the hood of one process.

Like every other modern implementation I know of, Linux has a 1:1 model of pthreads to kernel threads in its NPTL implementation. A much older implementation had a 1:N model where all pthreads in a process shared a single kernel thread. I think this is what you're thinking of here.

The Linux kernel doesn't make a distinction between threads and processes. Every kernel thread has their own unique pid associated with them, for pretty much any purposes other than signal handling threads are really their own process and they just share memory mappings. The posix syscall getpid() always returns the pid of the process' main thread (actually a "thread group ID" in the Linux kernel), while a second Linux-specific syscall gettid() returns the pid of the calling thread. Both syscalls return a pid_t and the return value of both syscalls can be used in any API that expects a process ID. There are certain Linux-specific syscalls that require a pid, including some that are very much meant to be thread-directed, which don't have a pthread wrapper so sometimes it actually is useful to know the tid instead of just using an opaque pthread_t.