Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!shelby!helens!baroque!jim From: jim@baroque.Stanford.EDU (James Helman) Newsgroups: comp.sys.sgi Subject: Re: Crashing the window mgr from GL programs Message-ID: Date: 4 Aug 90 22:19:16 GMT References: <1990Aug3.075057.11705@cs.umn.edu> <11361@odin.corp.sgi.com> <1990Aug3.230919.19543@jarvis.csri.toronto.edu> Sender: news@helens.Stanford.EDU Organization: Stanford University Lines: 46 In-reply-to: drb@eecg.toronto.edu's message of 4 Aug 90 03:09:19 GMT >>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@KAOS.stanford.edu) Voice: (415) 723-9127