3 Aug
2021
3 Aug
'21
9:51 a.m.
Bakul Shah writes:
On Aug 2, 2021, at 6:49 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
Not my experience. At least from what I was working on the 1980s
there was a need to be able to keep complicated state in graphical
programs which is when assembly language versions of threads came
into being. Made it possible for whatever was generating output
to be interrupted so that input could be handled in a timely manner.
I seem to recall getting some code from Sun for this that I ported
to a different system.
Jon
Bakul Shah writes:
AFAIK pretty much all GUI frameworks are (or were) single threaded.
At least I don't see the GUI as the main motivation for threads.
I was mainly complaining about the complexity of graphics subsystem,
including user interaction. Don't see what fork() has to do with it. Or perhaps the issue is not having graphics/GUI
designers with the
creativity and sensibilities of the early Bell Labs crowd of researchers?
I keep thinking there ought to be something simpler/more elegant than
the current graphics subsystems....
I thought that I posted something about this recently when someone
was arguing for threads being unnecessary and bad.
My two cents is that GUIs were the big driver for threads. I would
personally like to get rid of them as they're "the same but different"
with regards to processes. My preference would be to solve the
heaviness of processes problem. I'm not in the thick of that these
days, but I don't see it being solved in software alone; it's going
to take some serious hardware/software architecture work. Might be
easier to accomplish now that the world has pretty much settled on
the process model.
Jon On Aug 2, 2021, at 11:16 AM, Adam Thornton
<athornton(a)gmail.com> wrote:
It's a measure of Unix having been wounded by its own success.
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.
>
> These days, the vast majority of Unix applications are "stuff people play with
on their phones."
>
> Adam