Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Yes, that's a possible way to do it better.  But it still will not prevent
>> leftover socket files in case Emacs exited precipitously.

> No, but if an instance finds a socket/server-file and no one answers
> its request, it can assume the socket is a leftover, because there's
> no one listening out there. There's a tiny possibility for a race
> condition, but it would still be nicer to the user than the current "I
> can assume nothing, so I'll overwrite" method used now.

I'm not sure which problem you're trying to solve.  I'm talking here about
the problem in emacs.bash which uses the existence of the socket to decide
whether there is a live server or not.

Given the possibility of an Emacs crash leaving a dead socket, this
technique is simply not good enough.  Especially since you'll want to
connect to that socket anyway, so why not first try to connect: if it
succeeds keep on with the actual communication and if it fails then you know
for sure that there's no server available.  That's exactly what the
`alternate-editor' arg does.

>> Not so sure since you don't whether whether you're talking (though the
>> socket) to yourself or to some other process.

> I thought the socket name includes the pid of the Emacs instance; the
> server-file certainly does, so for TCP sockets it's easy to know.

No, the socket name is a "constant" and needs to be constructed without
knowing the process id of the server.  I believe the same holds for the
server-file: the pid is inside the file, not in the file name.  For sockets
we don't have such a place to put this kind of info right now.


        Stefan