Path: utzoo!attcan!utgpu!watmath!att!dptg!rutgers!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!decwrl!sgi!msc@ramoth.esd.sgi.com
From: msc@ramoth.esd.sgi.com (Mark Callow)
Newsgroups: comp.sys.sgi
Subject: Re: Icon questions
Summary: the fix
Message-ID: <41164@sgi.sgi.com>
Date: 31 Aug 89 00:05:28 GMT
References: <8908091355.AA16279@lerc08.lerc.nasa.gov>
Sender: msc@ramoth.esd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 43

In article <8908091355.AA16279@lerc08.lerc.nasa.gov>, fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) writes:
> 
> We are beginning to acquire quite an installed base of Personal Iris's here at
> the lab, and one strange problem has come up on several occassions.  There are
> several icons that get started by the system (tools, windows, and demos, I 
> think) and we add a few local ones to the "user.ps" in the /usr/NeWS/lib
> directory for all to use.  Each user may then add a couple of their own.
> 
> Why is it that sometimes, not all of the icons get fired up??  This seems to
> happen more frequently on the 8Meg systems than on the 12 and 16Meg ones. 
> One user complained that she actually got two of the same icon?  Is this 
> possible (without starting a second "chest" from the command line, of course)?

The missing toolchests (as we call them):
    I assume you are running 3.1 Revision D.  There is a race condition that
    has been present since release 3.0 but for some reason didn't show up until
    now.

    The fix is to edit the file /usr/NeWS/lib/NeWS/init.ps and move the call
    to "StartMostThings" to the end of the function "go!" just before this
    line:

	StartMostThings
	systemdict /cursorfont known {/ptr /ptr_m setRootCursor} if

    I don't have a release 3.1D system available to be make diffs, sorry.
    I posted the fix a few weeks ago.

    This is fixed in Rev G and Release 3.2.

The duplicate chests:
    I don't know anyway to do this except to run the chest commands again.

The random ordering:
    This happens because we are forking unix processes to connect to the
    server and the order they connect in is at the mercy of the Unix
    scheduler.  In release 3.2 we have created a utility called seqfork
    that waits for the connection to happen before returning.  This
    gives us a guaranteed order at the expense of a slightly slower startup.


--
	-Mark