lkml.org 
[lkml]   [2001]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Alan Cox quote? (was: Re: accounting for threads)
Date
On Tuesday 19 June 2001 19:31, Timur Tabi wrote:

> Amen. This is one of the reasons why I also prefer OS/2 over Linux.

Preferred.

OS/2's day has come and gone. IBM killed it with a stupid diversion into the
power PC version between 1993 and 1995. By the time Windows 95 was released,
MS had finally (after 11 years) managed to properly clone the original 1984
macintosh, and 90% of the PC user base was no longer actively looking to
replace their OS (Windows 3.1 and/or DOS). The window of opportunity for a
proprietary OS to replace Microsoft's had closed, and OS/2 4.0 was just plain
too late. (If it had been released two years earlier, things might have been
different. But it wasn't.)

But the window to commoditize a propreitary niche never closes. The PC
clones didn't care whether digital's minicomputers or IBM's mainframes won
out in the marketplace, they were quite happy to replace both. Linux is
winning because it's free software, not for whatever transient technical
reasons make one version of an OS better than another on a given day.

> 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?

I know, and I'm sorry I rescued FI from the corpse of OS/2 for the Power PC.
But it was my job, you know. :) (And I did rewrite half of it from scratch.
Before that it didn't work at ALL. There were algorithms in there that
scaled (failed to scale) to n^n complexity on the object hierarchy.
Unfortunately, IBM wouldn't let me rewrite the other half of it, and most of
that was pretty darn obnoxious and evil.)

Isn't it interesting that OS/2 turned into a unix platform? (EMX and gcc,
where all the software was coming from? I think I tried to point that out to
you when I attempted to recruit you into the LInux world at that gaming
session at armadillocon in... 1999? Glad to see you did eventually come over
to the chocolate side of the force after all... :)

> 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.

And in Linux you can create a time-critical process that shares large gorps
of memory where you keep your global variables, and call it a thread, and it
works the same way.

My only real gripe with Linux's threads right now (other than the fact they
keep trying to get us to use the posix api, which sucks. What IS an event
variable. What's wrong with event semaphores?) is that ps and top and such
aren't thread aware and don't group them right.

I'm told they added some kind of "threadgroup" field to processes that allows
top and ps and such to get the display right. I haven't noticed any
upgrades, and haven't had time to go hunting myself. (Ever tried to sumit a
patch to the FSF? They want you to sign legal documents. That's annoying.
I usually just send the bug reports to red hat and let THEM deal with it...)

> 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.

Yup. OS/2 is the largest nest of trained, experienced multi-threaded
programmers. (And it takes a LOT of training experience to do threads
right.) That's why I've been trying to recruit ex-OS/2 guys over to Linux
for years now. (Most followed Java to Linux after Netscape opened up
Mozilla, but there used to be several notable holdouts...)

Threading is just another way to look at programming, with both advantages
and disadvantages. You get automatic SMP scalability that's quite nice if
you keep cache coherency in mind. You get great latency and responsiveness
in user interfaces with just one or two extra threads. (State machines may
be superior if implemented perfectly, but like co-operative multitasking
(which they are) it's trivially easy to block the suckers and hang the whole
GUI. If you hang one thread, you can even program another thread to notice
automatically and unwedge it without much overhead at all. Trying to unwedge
a state machine is a little more complicated than kill/respawn of a thread.
Of course a perfect state machine shouldn't have those problems, but when you
interface with other people's code in a large system, you accept imperfection
and make the system survive as best it can.)

> 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 .....

Ah, don't pick on Linus. It's not exactly like the limiting factor to kernel
development is a SHORTAGE of patches sent in to the various maintainers.

Linus's job is to keep code OUT of the kernel. He has veto power, nothing
else. I suspect he's pre-emptively vetoing some stuff to keep the flood down
to a level he can deal with. Maybe someday we'll convince him to use some
variant of source control (not necessarily CVS, how about just a seperate
mailing list of the individual patches as he applies them? One linus can
post to and that is read-only to everybody else? HE always wants patches
seperated down nicely into individual messages with explanations, but WE have
to get pre2-pre3 as one big patch lump. With a patches-from-linus mailing
list that he forwarded posts to, we'd know exactly when a patch went in and
who it was from without bothering Linus. :)

Maybe something like that would allow a bit more decentralization, and then
he'd feel like he could keep his head above water if he allowed in a kernel
debugger. Who knows?

Rob
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:1.129 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site