On 10/22/2026 07:50, boltar@battlestar.co.uk wrote:

On Wed, 21 Oct 2026 19:01:38 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

In article <11bb1da$qfn9$1@dont-email.me>, <boltar@battlestar.co.uk> wrote: >>> Not sure why you think its conspiracy anything. I use the language on a

daily basis and everytime a new version comes out I hope they've added
something useful but since 2014 its been a law of diminishing returns.
Plus there's unexplained omissions - eg threads have been part of the core >>> language since 2011. Great, but what about processes? When do we get them? >>> Sure, I could just use fork() but then I could also just use pthread_create()
too.

One can implement a pretty reasonable threads library given the
virtual machine model of standard C or C++. Processes? With

Virtual machine? Wrong language , comp.lang.java is that way --->

their own address spaces, credentials, resource limits, IPC
mechanisms, potentially running different programs, and so on?

Not so much. You need an operating system for that, son.

You need an OS to do threading properly too. Theres a reason green threads
in java were a joke.

Processes are almost self-contained virtual machines. Unix has one of
the cleanest implementations around, and the fork() system call combined
with copy-on-write is very elegant. None of the other operating system I
have worked with have anything remotely like it. VMS was also quite
elegant, but so different that I think it would be impossible to
simulate one on the other (in either direction).

Threads are much simpler. Multiple strands of execution in a shared
address space. All the language needs to do is provide one shared
vocabulary to allow code portability.

To me it is obvious that threads can and should be standardized, while processes are generally not portable.

But if you hotheads can't agree on that, can you please now agree to
disagree and shut up!
--
Lars Poulsen - an old geek in Santa Barbara, California

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Threads and processes (Re: ?The end of software secrecy is almost upon)

On Mon, 26 Oct 2026 19:14:57 -0700, Lars Poulsen wrote:

Processes are almost self-contained virtual machines. Unix has one
of the cleanest implementations around, and the fork() system call
combined with copy-on-write is very elegant. None of the other
operating system I have worked with have anything remotely like it.
VMS was also quite elegant, but so different that I think it would
be impossible to simulate one on the other (in either direction).

Remember that copy-on-write was a later addition. Early Unix systems
had much more primitive memory management than VMS. But they did catch
up.

VMS had this odd distinction between ?subprocesses? and ?detached
processes?. You didn?t need special privilege to create the former
(though it was limited by a process quota), but you did for the
latter. And there were the idiosyncrasies of the ?UIC? business, which
were a hangover from RSX-11.

Why were login processes initially created under a UIC of [10,40]? (In
octal, no less.)

The one clever thing about VMS that I miss most on Linux systems was
the terminal driver. The functionality of that was a wonder to behold.

Threads are much simpler. Multiple strands of execution in a shared
address space. All the language needs to do is provide one shared
vocabulary to allow code portability.

There are some gotchas. Threads can be a notorious source of
hard-to-find bugs. Note how the POSIX spec defines ?cancellation
points?, which are a detailed list of system service/userland API
calls where the thread could potentially get force-terminated on
request from another process thread, as opposed to having it happen at
any time.

To me it is obvious that threads can and should be standardized, while processes are generally not portable.

What about a system like Linux, where the two are really just points
on a spectrum of possibilities?

<https://manpages.debian.org/clone(2)> is the underlying common kernel
call that is used to implement both fork(2) and pthread_create(3) on
Linux.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)