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

[Ulrich Mueller <ulm@kph.uni-mainz.de>]

>>>>> On Sat, 22 Nov 2008, Juanma Barranquero wrote:

>> 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.

If you assume that the user's home directory is NFS mounted, then this
is the normal case.

> 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.

Yeah, I see the problem that one wouldn't like to have network
timeouts here ...

> 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.

Agreed, of course a partial fix is better than not checking at all.
And I would vote against renaming the function, since I think its
intention is to find out if a server is running. Even if the
implementation (at the time being?) uses some heuristic that doesn't
cover 100% of all cases.

Another question, is the plan now to call server-running-p from
server-start (and refuse to start if it is returning non-nil)?

Ulrich