Still are. But goroutines are o.k. :)
Why Threads Are a Bad Idea (1995) [pdf]
11–20 of 103 posts
Re: Why Threads Are a Bad Idea (1995) [pdf]
#12The source of the article, Sun, is interesting. I guess the author knew what was about to be foisted upon the world. Kudos for trying to warn us. (I remember reading Novell and OS/2 documentation in the late 80s / early 90s about threads and recoiling in horror. Of course, all real men must use threads, cuz they’re faster, even if stupefyingly dangerous)
The author is John Osterhout, a CS professor. He was working at Sunlabs at the time. It's not like some unknown lone voice from the bowels of Sun was 'trying to warn us'. Warn us about what, anyway?
There was a hype wave about multithreading (hey BeOS) that started around 1995.
Re: Why Threads Are a Bad Idea (1995) [pdf]
#13Just FMI: the "events" approach that's recommended in the article over threads, that's how Python libraries like tornado and twisted work, right? And to what extent does the new asyncio Python library assume that functionality?
Yep. Twisted, Tornado, and asyncio are all built on the concept of event loops.
Re: Why Threads Are a Bad Idea (1995) [pdf]
#14There is a response to this: Why Events Are A Bad Idea
(for high-concurrency servers)[0]
[0]: https://people.eecs.berkeley.edu/~brewer/papers/threads-hoto...
Re: Why Threads Are a Bad Idea (1995) [pdf]
#15Just FMI: the "events" approach that's recommended in the article over threads, that's how Python libraries like tornado and twisted work, right? And to what extent does the new asyncio Python library assume that functionality?
Events don't share mutable state (at least implicitly), they carry a copy of data. This eliminates a huge class of thread-related errors.
The canonical thing that works this way is Erlang (and its modern cousin, Elixir). See also "actor model" (e.g. Akka). It is approximately how Windows and Mac GUI used to work (back in the day; did not look at these APIs for ~20 years).
Python async is coroutines, a different kind of concurrency. In it, the event loop is hidden, and coroutines just yield control, implicitly or explicitly, to allow other coroutines proceed. In Python, a CPU-bound task can only run on a single thread, due to the Global Interpreter Lock preventing concurrent modification of data. Coroutines are still useful both for IO and as a general way to describe intertwined, mutually dependent computations. (The earliest, limited Python coroutines were generators.)
Re: Why Threads Are a Bad Idea (1995) [pdf]
#16I have seen that argument in the past but somehow still can't see how event-based approach saves us from the headaches of concurrency.
If you need to deal with parallel processing (which is relatively often in the real world) you WILL have to face the problems of consistency, visibility and program order.
Many languages don't even require programmers to have much exposure to threading mechanics. It's an OS responsibility, and that's not necessarily a bad thing.
Re: Why Threads Are a Bad Idea (1995) [pdf]
#17Earlier quoted context omitted.
Somebody better tell the Node.js cluster guys :-) They manage without threads pretty well, I think. Shared state is deliberate, outside of individual processes, rather than accidental in-process. As it should be unless you are doing some serious systems level programming.
To be fair, node.js just merged the --experimental-workers module for actual webworker-style threading.
Does it allow shared (immutable) data structures?
I.e. does it allow passing large parts of data structures without copying?
Re: Why Threads Are a Bad Idea (1995) [pdf]
#18Still are. But goroutines are o.k. :)
Some think otherwise: https://news.ycombinator.com/item?id=16921761
A pretty valid critique, and a reasonable solution offered.
Re: Why Threads Are a Bad Idea (1995) [pdf]
#19Yep, they might be a good solution on resource constrained hardware, but we learned hard how bad they are from security and stability point of view.
In that regard process are much better solution.
Re: Why Threads Are a Bad Idea (1995) [pdf]
#20[deleted]