3 ms·

I don't know the history of threads/NPTL on Linux. However, the distinction between "thread" and "process" in the Linux kernel is mostly a human one, not a tech

I don't know the history of threads/NPTL on Linux. However, the distinction between "thread" and "process" in the Linux kernel is mostly a human one, not a technical one. Take a look at the clone() syscall -- spawning a thread vs. forking a process amount just to different flags to that call, to tell it whether to copy pages or not, how to assign a new ID to the new thread/process, etc. (Not sure if that's how fork() and friends are actually implemented under the hood.)

cbd1984 11y ago
> (Not sure if that's how fork() and friends are actually implemented under the hood.) If you use strace you can see that it is. fork(2) and pthread_create(3) both show up as calls to clone(2).
- cbd1984 11y ago
  Just for the edification of the masses: pthread_create(3) looks something like this: clone(child_stack=0x7f79d754bff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f79d754c9d0, tls=0x7f79d754c700, child_tidptr=0x7f79d754c9d0) = 31230 (Newlines are mine.) Of course, those pointers are only that size on a 64-bit architecture. The flags are where the real point of interest is. fork(2) is like this: clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f543a9aaa10) = 17978 When implementing fork(2), the return value from clone(2) is the child's PID from the context of the parent process. When implementing pthread_create(3), the return value for the parent is still an integer value which is unique to the thread, and which strace uses as if it were a PID when it's tracing down the system calls of individual threads in separate files, which strace can do because it's awesome. Some more information: > Linux has a unique implementation of threads. To the Linux kernel, there is no concept of a thread. Linux implements all threads as standard processes. The Linux kernel does not provide any special scheduling semantics or data structures to represent threads. Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique task_struct and appears to the kernel as a normal process (which just happens to share resources, such as an address space, with other processes). http://www.makelinux.net/books/lkd2/ch03lev1sec3 http://www.makelinux.net/books/lkd2/ch03lev1sec3

cbd1984 11y ago

> (Not sure if that's how fork() and friends are actually implemented under the hood.) If you use strace you can see that it is. fork(2) and pthread_create(3) both show up as calls to clone(2).

cbd1984 11y ago
Just for the edification of the masses: pthread_create(3) looks something like this: clone(child_stack=0x7f79d754bff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f79d754c9d0, tls=0x7f79d754c700, child_tidptr=0x7f79d754c9d0) = 31230 (Newlines are mine.) Of course, those pointers are only that size on a 64-bit architecture. The flags are where the real point of interest is. fork(2) is like this: clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f543a9aaa10) = 17978 When implementing fork(2), the return value from clone(2) is the child's PID from the context of the parent process. When implementing pthread_create(3), the return value for the parent is still an integer value which is unique to the thread, and which strace uses as if it were a PID when it's tracing down the system calls of individual threads in separate files, which strace can do because it's awesome. Some more information: > Linux has a unique implementation of threads. To the Linux kernel, there is no concept of a thread. Linux implements all threads as standard processes. The Linux kernel does not provide any special scheduling semantics or data structures to represent threads. Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique task_struct and appears to the kernel as a normal process (which just happens to share resources, such as an address space, with other processes). http://www.makelinux.net/books/lkd2/ch03lev1sec3 http://www.makelinux.net/books/lkd2/ch03lev1sec3