> 2) Not only did Linux not have threads (at all), it didn't plan to have
> threads, and anybody who brought up the idea of threads was dismissed.
> Considering this was long before clone, and SMP hardware was starting to come
> into the high and and looked like it might wind up on the desktop eventually
> (who knew MS would keep DOS around another ten years, unable to understand
> two processors, to displays, two mice, two keyboards, and barely able to cope
> with two hard drives under a 26 letter limit...)
Amen. This is one of the reasons why I also prefer OS/2 over Linux.
> So I wound up work at IBM doing OS/2 development for a couple years. On a
> project called Feature Install, which was based on a subclassed folder in the
> workplace shell (object oriented desktop).
[snip]
> When they made up a test object hierarchy
> for all the components of the entire OS, it created so many threads the
> system ran out and got completely hosed. I had a command line window open,
> but couldn't RUN anything, since anything it tried to spawn required a thread
> to run. (Child of the shell.)
Feature Installer is a bad example. That software is a piece of crap for lots
of reasons, excessive threading being only one, and every OS/2 user knew it the
day it was released. Why do you think WarpIN was created?
> Sometimes they're an easy way to get asynchronous behavior, and to perform
> work in the background without the GUI being locked up. But the difference
> between "processes" and "threads" there is academic. Processes with shared
> memory and some variant of semaphores to avoid killing each other in it.
> Same thing.
Not quite. What makes OS/2's threads superior is that the OS multitasks
threads, not processes. So I can create a time-critical thread in my process,
and it will have priority over ALL threads in ALL processes.
A lot of OS/2 software is written with this feature in mind. I know of one
programmer who absolutely hates Linux because it's just too difficult porting
software to it, and the lack of decent thread support is part of the problem.
> Bondage and discipline languages that enforce somebody's idea of good
> programming practice usually just result in WORSE bad programs, and fewer
> good programs written by people who know how to play with fire without
> burning themselves. Saying you can't have threads because they can be
> misused and "you shouldn't program that way" would be truly dumb. (Turned ME
> off for a couple years, anyway.)
Exactly. Saying that threads cause bad code is just as dumb as saying that a
kernel debugger will cause bad code because programmers will start using the
debugger instead of proper design.
Oh wait, never mind .....
-- Timur Tabi - ttabi@interactivesi.com Interactive Silicon - http://www.interactivesi.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/