[slime-devel] long delay starting up slime on a computer off-line
When my computer is connected to the internet, M-x slime will get me a slime repl buffer immediately. However, if my computer is not connected to the internet, it takes much longer to get a slime repl buffer. There is a long wait while the mini buffer displaying "Connecting to Swank on port 35948...", after which there is another long wait while the mini buffer displaying "initial handshake...". The first delay is due to a call to OPEN-NETWORK-STREAM in SLIME-NET-CONNECT. Not sure about the 2nd delay, which is probably on the CL side. Is it possible to get rid of this long delay when starting up Slime on a computer off-line? Best, -cph
Chisheng Huang <cph@chi-square-works.com> writes:
When my computer is connected to the internet, M-x slime will get me a slime repl buffer immediately. However, if my computer is not connected to the internet, it takes much longer to get a slime repl buffer. There is a long wait while the mini buffer displaying "Connecting to Swank on port 35948...", after which there is another long wait while the mini buffer displaying "initial handshake...". The first delay is due to a call to OPEN-NETWORK-STREAM in SLIME-NET-CONNECT. Not sure about the 2nd delay, which is probably on the CL side. Is it possible to get rid of this long delay when starting up Slime on a computer off-line?
Sounds suspiciously like a DNS lookup. We actually make two network connections (one for the RPC channel and then one for streaming user output) so that would explain your delays. What platform are you running on? Off hand the only thing I can think of that could explain this is if you're on a GNU box and your /etc/nsswitch.conf says to check 'dns' before 'files' (i.e. goes to the network before checking /etc/hosts). I wonder if we should be saying "127.0.0.1" instead of localhost? We should also write a note about the security impliciations of the swank protocol, and note which backends at least manage to bind our listen-sockets on the loopback interface. -Luke
Sounds suspiciously like a DNS lookup. We actually make two network connections (one for the RPC channel and then one for streaming user output) so that would explain your delays.
What platform are you running on?
Red Hat 7.3 Linux on an Intel box and CMUCL 2004-06-29 snapshot. I cvs updated Slime on 2004-06-29. I first noticed this long delay in January this year.
Off hand the only thing I can think of that could explain this is if you're on a GNU box and your /etc/nsswitch.conf says to check 'dns' before 'files' (i.e. goes to the network before checking /etc/hosts).
I have the following in /etc/nsswitch.conf: hosts: files nisplus dns Thanks. -cph
Chisheng Huang <cph@chi-square-works.com> writes:
Sounds suspiciously like a DNS lookup. We actually make two network connections (one for the RPC channel and then one for streaming user output) so that would explain your delays.
What platform are you running on?
Red Hat 7.3 Linux on an Intel box and CMUCL 2004-06-29 snapshot. I cvs updated Slime on 2004-06-29. I first noticed this long delay in January this year.
Well, here are some random ideas: If you replace all occurances of "localhost" with "127.0.0.1" in slime.el, do the delays disappear? How about if you take down the network, e.g. 'ifdown eth0' or 'ifconfig eth0 down' If you don't already have it, put a line in /etc/hosts like: 127.0.0.1 localhost I don't know if I'm on the right track here. -Luke
participants (2)
-
Chisheng Huang -
Luke Gorrie