WTF, sleep-for?

WTF, sleep-for?

[Hrvoje Niksic]

I noticed that quitting Gnus has become noticably slower -- whereas
pressing `q' used to be fast, I now have to wait more than a second
for the Group buffer to disappear.

After sharping the profiling routines, what do I discover?  That the
time is being spent in a `sleep-for', presumably this one:

[... nntp-close-server ...]
	(ignore-errors
	  (nntp-send-string process "QUIT")
	  (sleep-for 1)))

Is there a reason for this?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!!

Re: WTF, sleep-for?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> After sharping the profiling routines, what do I discover?  That the
> time is being spent in a `sleep-for', presumably this one:
> 
> [... nntp-close-server ...]
> 	(ignore-errors
> 	  (nntp-send-string process "QUIT")
> 	  (sleep-for 1)))
> 
> Is there a reason for this?

If you `delete-process' an rsh process, it will most likely die before
this QUIT arrives, which means that the NNTP server will keep its
connection open until it dies of boredom.  Which is naughty.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: WTF, sleep-for?

[Jan Vroonhof]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If you `delete-process' an rsh process, it will most likely die before
> this QUIT arrives, which means that the NNTP server will keep its
> connection open until it dies of boredom.  Which is naughty.

isn't it better to also have an nntp-close-connection-function which
waits for "Remote dropped connection" or something like that.
The timeout seem rather arbitrary.

Jan

Re: WTF, sleep-for?

[Lars Magne Ingebrigtsen]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> isn't it better to also have an nntp-close-connection-function which
> waits for "Remote dropped connection" or something like that.

Yes, that would perhaps be better, but in most cases (that is, when
using the normal connection function) just sending a QUIT and killing
the process gets the job done -- and done very quickly from a user
standpoint.  Waiting to see if the link is actually dropped by the
server can sometimes take a while -- and if the IP address of the
machine has changed, then it'll take forever.

> The timeout seem rather arbitrary.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: WTF, sleep-for?

[Thor Kristoffersen]

Hrvoje Niksic writes:
> [... nntp-close-server ...]
> 	(ignore-errors
> 	  (nntp-send-string process "QUIT")
> 	  (sleep-for 1)))
> 
> Is there a reason for this?

If you connect to the news server with `nntp-open-rlogin' (or a
similar method) you have to make sure that the "QUIT" makes it to the
news server before you kill the connection, otherwise the
telnet-process on the other server won't terminate.

An improvement would be to check `nntp-open-connection-function' and
(sleep-for 1) only when necessary.


Thor
-- 
Thor Kristoffersen

Re: WTF, sleep-for?

[Hrvoje Niksic]

Thor Kristoffersen <thor@unik.no> writes:

> If you connect to the news server with `nntp-open-rlogin' (or a
> similar method) you have to make sure that the "QUIT" makes it to the
> news server before you kill the connection, otherwise the
> telnet-process on the other server won't terminate.

This is very annoying for those of us who don't use
`nntp-open-rlogin'.  As you continue:

> An improvement would be to check `nntp-open-connection-function' and
> (sleep-for 1) only when necessary.

Lars, could you *please* conditionalize the `sleep-for'?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Which is worse: ignorance or apathy?  Who knows?  Who cares?

Re: WTF, sleep-for?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > An improvement would be to check `nntp-open-connection-function' and
> > (sleep-for 1) only when necessary.
> 
> Lars, could you *please* conditionalize the `sleep-for'?

Yup.  Fix in Quassia Gnus v0.18.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: WTF, sleep-for?

[Felix Lee]

> > > An improvement would be to check `nntp-open-connection-function' and
> > > (sleep-for 1) only when necessary.
> > Lars, could you *please* conditionalize the `sleep-for'?

or else you could wait for the 205 response to the QUIT
--

Re: WTF, sleep-for?

[Jan Vroonhof]

Thor Kristoffersen <thor@unik.no> writes:

> If you connect to the news server with `nntp-open-rlogin' (or a
> similar method) you have to make sure that the "QUIT" makes it to the
> news server before you kill the connection, otherwise the
> telnet-process on the other server won't terminate.

Why? Won't it be killed automatically when the connection is closed?
Sure seems to work like that here.

Jan

Re: WTF, sleep-for?

[Thor Kristoffersen]

Jan Vroonhof writes:
> > If you connect to the news server with `nntp-open-rlogin' (or a
> > similar method) you have to make sure that the "QUIT" makes it to the
> > news server before you kill the connection, otherwise the
> > telnet-process on the other server won't terminate.
> 
> Why? Won't it be killed automatically when the connection is closed?
> Sure seems to work like that here.

Sheer luck.  I wasn't so lucky, though; not long ago one system
administrator kindly pointed out to me that I had about 30 old telnet
processes lying around on a heavily loaded server.  They were all left
there by `nntp-open-rlogin'.


Thor
-- 
Thor Kristoffersen

Re: WTF, sleep-for?

[Jan Vroonhof]

Thor Kristoffersen <thor@unik.no> writes:

> Sheer luck.  I wasn't so lucky, though; not long ago one system
> administrator kindly pointed out to me that I had about 30 old telnet
> processes lying around on a heavily loaded server.  They were all left
> there by `nntp-open-rlogin'.

Well it seems to me that there must be something wrong. I am not a
unix internals guru, but seems to me that the telnet must get
terminated at the time where NNTP server closed the connection because 
of timeout and it tries to write "remote has closes connection" to the
nonexistent socket connection.

Jan