Re: Alan Cox quote? (was: Re: accounting for threads)

[Rob Landley <landley@webofficenow.com>]

On Friday 22 June 2001 10:46, Mikulas Patocka wrote:

> I did some threaded programming on OS/2 and it was real pain. The main
> design flaw in OS/2 API is that thread can be blocked only on one
> condition. There is no way thread can wait for more events. For example 

Sure.  But you know what a race condition is, and how to spot one (in 
potential during coding, or during debugging.)  You know how to use 
semaphores and when and why, and when you DON'T need them.  You know about 
the potential for deadlocks.

And most of all, you know just because you got it to run once doesn't mean 
it's RIGHT...

> When OS/2 designers realised this API braindamage, they somewhere randomly
> added funtions to unblock threads waiting for variuos events - for example
> VioModeUndo or VioSavRedrawUndo - quite insane.

OS/2 had a whole raft of problems.  The fact half the system calls weren't 
available if you didn't boot the GUI was my personal favorite annoyance.

It was a system created _for_ users instead of _by_ users.  Think of the 
great successes in the computing world: C, Unix, the internet, the web.  All 
of them were developed by people who were just trying to use them, as the 
tools they used which they modified and extended in response to their needs.

This is why C is a better language than pascal, why the internet beat 
compuserve, and why Unix was better than OS/2.  Third parties writing code 
"for" somebody else (to sell, as a teaching tool, etc) either leave important 
stuff out or add in stuff people don't want (featuritis).  It's the nature of 
the beast: design may be clever in spurts but evolution never sleeps.  
(Anybody who doesn't believe that has never studied antibiotic resistant 
bacteria, or had to deal with cockroaches.)

> Programming with select, poll and kqueue on Unix is really much better
> than with threads on OS/2.

I still consider the difference between threads and processes with shared 
resources (memory, fds, etc) to be largely semantic.

> Mikulas

Rob