[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

It's Alive

    Date: Wed, 20 Sep 89 11:23:04 EST
    From: bouma@cs.purdue.edu

	Why is it that when I make changes to the NAMESPACE some of the
    machines don't notice? For instance, one machine on the network went
    away, and we got another (unix machines), so I edited the namespace
    appropriately. But some of the machines still list that deleted machine
    as a dead connection in PEEK on NETWORK? Rebooting does not help, but
    Reset Network gets rid of it until the next time I reboot.

As the Namespace Editor tells you when it finishes saving an object:
 Other servers and hosts will not get updates until they ask something of the
Primary Server. 

This is by design.  Changes to the namespace are not broadcast; at a large
site like Symbolics or MIT, the constant barrage of changes would swamp the
network.  To keep network traffic to a minimum, the namespace server only
sends information in response to a query by another machine.  :Reset Network
forces a namespace update by calling NETI:INITIALIZE-NAMESPACES-AND-NETWORK,
which asks the server for a quick update.  This function is supposed to be
called at cold and warm boot as well.

	How is it that all the lisp machines know about the new machine I
    added, but some still think the one I deleted is out there? Is info
    cached in a world file overriding the present namespace? Does this
    behavior conform with the way the namespace works, or it is a local
    bug in our system?

In part this is because the theory of deleting objects from the namespace has
some loopholes, in part it's because there is a bug in the deletion code which
leaves known deleted objects in a cache.  I am working on a solution to the
latter problem.

	A few days ago I logged into a freshly booted machine as 
    LISP-MACHINE. I then edited and attempted to save a file. Instead
    of saving the file, the machine writes, "Who are you really?"!

    Bill <bouma@cs.purdue.edu>  ||  ...!purdue!bouma 

This is a feature; if you supply a user name, the operation proceeds.  The
user name that you supply is not checked in any way.

Logging in under any user ID with a type field of DAEMON in the namespace will
cause this behavior.  It's intended to remind conscientious users to identify
themselves when saving files (et al) under an alias.  Of course, there's
nothing preventing less conscientious people from supplying another alias.

 -- Chuck Fry (Chucko@Riverside.SCRC.Symbolics.COM)
    Symbolics Software Support