| ▲ | PaulDavisThe1st 2 hours ago | |||||||||||||
A more accurate way to describe this is that Windows' (NT onward) core execution context model is a bunch of threads that by default share memory, whereas Unixen have a core task context model of a bunch of threads that by default do not share memory. Both systems are implemented using threads as the execution context, but in Unix, the history means that that you fork+exec most of the time, resulting in a two tasks that do not share memory any more. By contrast, on Windows (NT onward) the common case when creating a new execution context is to create a thread that shares memory with others in its process. Both systems allow the easy use of the other's core abstraction. On Unix, you can either code like its 1986 and use fork without exec, or use clone(3) or any of its higher level abstractions like pthreads. You're right that POSIX semantics get tangled when using threads. | ||||||||||||||
| ▲ | pjmlp an hour ago | parent | next [-] | |||||||||||||
Well, Windows before NT isn't the same design as Windows 16 bit, it only shares the name for all practical purposes, and has more influence from OS/2 than Windows 16 bit. Which is why I took the effort to explicitly refer to Windows NT on my comment, already expecting some traditional answers from UNIX folks. Also due to historical reasons POSIX threads are the outcome of every UNIX going their own way implementing threads, finally coming to an agreement years later, with all the plus and minus of relying in POSIX for portable code. | ||||||||||||||
| ▲ | snozolli an hour ago | parent | prev [-] | |||||||||||||
whereas Unixen have a core task context model of a bunch of threads that by default do not share memory. How are those not simply child processes? I don't understand your use of the word 'threads' here. Does the Unix world not distinguish between threads and processes? In Win32, threads exist within processes, and you can create new threads or child processes. | ||||||||||||||
| ||||||||||||||