Re: error in server-running-p on M$

[Juanma Barranquero]

On Sat, Nov 22, 2008 at 16:35, Ulrich Mueller <address@hidden> wrote:

> As an example: The auth file is on an NFS mounted filesystem, and the
> Emacs server is running on the machine of the NFS server.

You're approaching my original question: what is the intended use of
`server-running-p', and how do we want it to work when different
instances of Emacs use different server setups. Of course there is no
problem in having several servers, even on the same machine. The
problem is one hiding the other.

For your case to be a problem, you must be starting a server in the
local machine set up such its authentication file clobbers the one on
the NFS server. That is one instance of the problem I discussed, but
you don't need such a complicate setup. Just start a local TCP server,
and then another with the same server name. Lo, you just rendered the
first one inaccessible.

> How would assigning a random port number help here?

> With the proposed test, server-running-p will return nil in this case,
> since it will find an auth file but no associated Emacs process.

It only will do that if the current, local server is trying to write
an authentication file in the NFS server. Else, it won't even *find*
the authentication file, so it will write its own, and start a new,
local server with a random port that won't collide with the NFS
server's Emacs server.

Still, the point is, either we try to do a complicate,
potentially-network-delaying check, or we opt for a simple,
not-totally-reliable check. I don't mind one way or the other (though
I won't be writing the complex one), but we should bear in mind that
even if the check fails, consequences are hardly catastrophic.
Currently we don't even check, just clobber the auth file. So any
partial fix is a net benefit, as long as we rename the function and/or
write a clear docstring stating that it cannot be assumed to be a
reliable indicator of the presence of another Emacs instance.

             Juanma