At least on Linux, processes and threads are not that much different. You create both with clone(2) call which accepts a large number of flags (see https://linux.die.net/man/2/clone ). Depending on the flags you pass, you can get a new thread, or a new process, or something inbetween. For example, how about a "thread" which has it's own memory space (~CLONE_VM)?

I know, but that is very Linux specific and not something that can be generalized in a portable way across UNIX implementations.

You cannot generalize scheduling primitives across UNIX implementations.

To quote the FreeBSD manual: "Traditional UNIX® does not define any API nor implementation for threading, while POSIX® defines its threading API but the implementation is undefined."

macOS was at least temporarily considered a true UNIX, and the scheduling primitive there is a Mach task. I frankly don't remember much about FreeBSD anymore, but I would assume that the unit of scheduling there is somewhat identical to that of Linux... Just implemented nicer.

That is the whole point, Linux != UNIX, yet every time someone discuss some UNIX feature, there comes a Linux example as if Linux would the be representative of how UNIX works.

That's not what happened here. In this case, someone discussed Windows, Linux and macOS features and implementation details, and someone (you) came around and started talking about UNIX. ;)

You seem to be distracted by terms rather than their meaning.

The primary difference between Windows and Linux (which is the topic at hand, not other Unixes or esoteric OS's) is in terminology. A Windows "process" is not the same as a Linux "process". A Windows "thread" is not the same as a Linux "thread".

However, a Windows "execution resource" ("thread") is quite identical to a Linux "execution resource" ("process"), or the macOS "execution resource" ("Mach task", not "process" or "thread").

Windows and Linux also have "execution resource groups", in the form of "process" and "thread group"/"parent process", respectively. They are implemented slightly differently (dedicated device vs. "master" execution resource), but the end-result is similar.

These constructs implement identical functionality for all intents and purposes (the differences are just in some minor limitations and API choices). The scheduler only operates on the execution resource, but might look at the execution resource group when making scheduling decisions. This is shared between all the OS's, and is a minor implementation detail that can change between releases.

The distinction between "thread-based" and "process-based" does not exist. Linux is a heck of a lot faster to create "resource groups" than Windows is, but that is due to better code, not fundamental design limitations.

(Of course, an esoteric OS might implement something entirely different from the concepts of "processes" and "threads", but that's a fun discussion for another day—the important thing is the contemporary OS's are all the same.)

Note that in linux, threads are the unit of scheduling, not processes.

Conceptually yes, but note that in Linux there is no such thing as a thread. Only processes. Some of those processes happen to share an address space and belong to a thread-group (TGID), but they are all processes.

This only really matters when you're trying to understand how PID, PPID, and TGID fit together and why there is no TID, though.

True, but Linux and UNIX are not the same thing, even though many keep mixing it up.

Actually, Linux is very explicit about not being a UNIX.

However, the topic would appear to be Windows, Linux and potentially also macOS. That's what the benchmarks are about. No one mentioned other OS's.

Which is why no one should use it as an example how UNIX works.

No one is! You're the one who brought up UNIX. The rest of us is commenting on a benchmark of specifically Windows, Linux and macOS. Only one of those was temporarily considered UNIX, and most disagreed with the label.