3 Aug
2021
3 Aug
'21
5:21 a.m.
On Aug 2, 2021, at 6:49 PM, Jon Steinhart
<jon(a)fourwinds.com> wrote:
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.
Has it, though? Most of the stuff I’m working with right now is either asyncio and
Python, or Javascript, both of which are very much about threading.
I think there’s a lot of stuff that does work better with multiple program counters for
different things executing at the same time with shared access to memory, although of
course reasoning about concurrency is always hard and having to manage locks on things
that shouldn’t be shared _right now_ is a lot of work and easy to get wrong.
I like Go and goroutines and channels as an intra-process communication mechanism.
My problem with processes, in the traditional sense, is that there ARE often pieces of
state you want to share between the things concurrently acting on that state. A
channel-like mechanism could work as IPC, but, equally well, why _not_ have multiple
things—we can call them threads if you want—that can just see that shared state?
Adam