Re: [TUHS] Systematic approach to command-line interfaces

[Adam Thornton <athornton@gmail.com>]

> On Aug 2, 2021, at 6:49 PM, Jon Steinhart <jon@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