Crashing the window mgr from GL programs

James Helman jim at baroque.Stanford.EDU
Sun Aug 5 08:19:16 AEST 1990


>>It would be more worthwhile for SGI to make GL safer to use, even at
>>some expense in performance.

> I disagree.  Having a separate checking version of the library (say the
> unshared version) would be better.  Then once you have some confidence your
> code works you can link with the high performance version which doesn't
> do checking.

I can't object to giving the user the freedom to decide the
safety/performance level.  If you *know* your program has no bugs
whatsoever, go for it.

But I don't want it to be a choice between a no-checks-made
"production" version GL which runs at full speed, and a test version
that runs at half speed.

I would argue that safety features which slow performance down
slightly (say less than 10%) should be included standard.  From a
marketing perspective, SGI outclasses other platforms by so much that
10% less performance would be well worth the improved reputation that
would come from more robustness.  And I'm sure a lot of it could be
designed into the hardware with virtually no performance loss at all.

I've seen too many complex programs in which the "unsafe" sequence was
not tickled until demo time.  Presumably, the authors also had "some
confidence" in their code before they put it on display.  But when one
sees a failure, which is indistinguishable from a hardware or system
software problem, it doesn't matter who's too blame.  It makes the
machine look like an unstable platform.  After a non-technical
management type sees a machine apparently crash and burn during a
demo, how much good will it do to explain: ... application bug ... bad
sequence ... locked pipe ... may be bad hardware.... but it's 10%
faster!

When a user program can easily and accidentally bring the entire
windowing system down, in my book, it's a bug.

Speaking of which, SGI's X server is much improved in IRIX 3.3.  Some
bugs remain, but (knock on wood) I haven't experienced a single core
dump.  Hats off to SGI's X team.  When's the next release?

Jim Helman
Department of Applied Physics			Durand 012
Stanford University				FAX: (415) 725-3377
(jim at KAOS.stanford.edu) 			Voice: (415) 723-9127



More information about the Comp.sys.sgi mailing list