3 Aug
2021
3 Aug
'21
9:01 p.m.
fork() is a great model for a single-threaded text
processing pipeline to do
automated typesetting. (More generally, anything that is a straightforward
composition of filter/transform stages.) Which is, y'know, what Unix is *for*.
It's not so great for a responsive GUI in front
of a multi-function interactive program.
"Single-threaded" is not a term I would apply to multiple processes in
a pipeline. If you mean a single track of data flow, fine, but the
fact that that's a prevalent configuration of cooperating processes in
Unix is an artifact of shell syntax, not an inherent property of
pipe-style IPC. The cooperating processes in Rob Pike's 20th century
window systems and screen editors, for example, worked smoothly
without interrupts or events - only stream connections. I see no
abstract distinction between these programs and "stuff people play
with on their phones."
It bears repeating, too, that stream connections are much easier to
reason about than asynchronous communication. Thus code built on
streams is far less vulnerable to timing bugs.
At last a prince has come to awaken the sleeping beauty of stream
connections. In Go (Pike again) we have a widely accepted programming
language that can fully exploit them, "[w]hich is, y'know, what Unix
is 'for'."
(If you wish, you may read "process" above to include threads, but
I'll stay out of that.)
Doug
3 Aug
3 Aug
11:13 p.m.
I always believed that fork() was the very essence of the beauty of UNIX.
So simple, yet so powerful. And it is far simpler than its predecessor on
Genie, which looked a lot more like spawn().
With fork, the child inherits properties which may not have existed when
the code was written, so it's much easier to reason about the behavior of
sub-processes. Fork made writing the shell and pipelines much more obvious.
Today we know that threads and shared mutable memory are a really bad idea,
it's just that the hardware gave us no alternatives. I claim UNIX is
directly responsible for the existence of MMUs in microprocessors. What if
CPU designers would add facilities to directly implement inter-process or
inter-processor messaging? Sadly, there has to be a dominant software
paradigm for the hardware guys to target, so there's a nasty chicken and
egg problem. Imagine if the Erlang model of distributed systems had taken
off. Go gets us part of the way there, but cross-machine messaging is
still a mess.
On Tue, Aug 3, 2021 at 8:02 AM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
--
- Tom
fork() is a
great model for a single-threaded text processing pipeline
to do
automated typesetting. (More generally, anything
that is a
straightforward
composition of filter/transform stages.) Which
is, y'know, what Unix
is *for*.
It's not so great for a responsive GUI in
front of a multi-function
interactive program.
"Single-threaded" is not a term I would apply to multiple processes in
a pipeline. If you mean a single track of data flow, fine, but the
fact that that's a prevalent configuration of cooperating processes in
Unix is an artifact of shell syntax, not an inherent property of
pipe-style IPC. The cooperating processes in Rob Pike's 20th century
window systems and screen editors, for example, worked smoothly
without interrupts or events - only stream connections. I see no
abstract distinction between these programs and "stuff people play
with on their phones."
It bears repeating, too, that stream connections are much easier to
reason about than asynchronous communication. Thus code built on
streams is far less vulnerable to timing bugs.
At last a prince has come to awaken the sleeping beauty of stream
connections. In Go (Pike again) we have a widely accepted programming
language that can fully exploit them, "[w]hich is, y'know, what Unix
is 'for'."
(If you wish, you may read "process" above to include threads, but
I'll stay out of that.)
Doug
12 Aug
12 Aug
12:11 a.m.
Tom Lyon via TUHS <tuhs(a)minnie.tuhs.org> writes:
What if CPU designers would add facilities to directly
implement
inter-process or inter-processor messaging?
You mean like INMOS's Transputer architecture from back in the late
eighties and early nineties? Each processor had a thread scheduling and
message passing microkernel implemented in its microcode, and had four
bi-directional links to other processors, so you could build a grid.
They designed the language Occam along with it, to be its lowest level
language; it and the instruction set were designed to match. Occam has
threads and message passing as built-in concepts, of course.
-tih (playing with the Helios distributed OS on Transputer hardware)
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
3:24 a.m.
I never had the pleasure of playing with Transputers, but it sounds nice.
Of course, I'd want the networking to be Ethernet/IP centric these days.
On Wed, Aug 11, 2021 at 11:11 AM Tom Ivar Helbekkmo <tih(a)hamartun.priv.no>
wrote:
Tom Lyon via TUHS <tuhs(a)minnie.tuhs.org>
writes:
--
- Tom
What if CPU designers would add facilities to
directly implement
inter-process or inter-processor messaging?
You mean like INMOS's Transputer architecture from back in the late
eighties and early nineties? Each processor had a thread scheduling and
message passing microkernel implemented in its microcode, and had four
bi-directional links to other processors, so you could build a grid.
They designed the language Occam along with it, to be its lowest level
language; it and the instruction set were designed to match. Occam has
threads and message passing as built-in concepts, of course.
-tih (playing with the Helios distributed OS on Transputer hardware)
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
1228
days inactive
1236
days old
3 comments
3 participants
participants (3)
-
Douglas McIlroy -
Tom Ivar Helbekkmo -
Tom Lyon