No. They are better -- while mostly keeping the same API. As statedabove, most multithreaded OSs define a thread separately from processes.Linus Torvalds has defined that a thread is a "context of execution"(COE). This means that only one process/thread table and one scheduleris needed. Also the scheduler has been optomized so that the switchingtime for threads vs. tasks varies little--about 1.7us (threads) and 1.8us(fork) on a 75MHz Pentium.
Traditionally, a thread was just a CPU (and some other minimal state)state with the process containing the remains (data, stack, I/O, signals).This would lend itself to very fast switching but would cause basic problems(e.g. what do "fork()" or "execve()" calls mean whenexecuted by a thread?).
Consider Linux threads as a superset of this functionality: they stillcan switch fast and share process parts, but they can also identify whatparts get shared and have no problems with execve() calls. There are fourflagsthat determine the level of sharing:
Clone Flag Values
| #define | CLONE_VM | 0x00000100 |
| #define | CLONE_FS | 0x00000200 |
| #define | CLONE_FILES | 0x00000400 |
| #define | CLONE_SIGHAND | 0x00000800 |
| #define | CLONE_PID | /* notfully implemented */ |
There has been a lot of talk about "clone()". The system call(please note: "low level") clone() is an extensionto fork(). In fact, clone(0) == fork(). But with the above #define's, anycombination of the VM, filesystem, I/O, signal handlers and process IDmay be shared.