Re: lynx-dev partial not working on ftp:// url's (?)

[Klaus Weide]

On Wed, 21 Jul 1999, Kim DeVaughn wrote:

> On Tue, Jul 20, 1999, Klaus Weide (address@hidden) said:
> |
> | > And it is the only (or 2nd) ^G that causes "Data transfer interrupted."
> | > to be displayed (along with the 1st screenfull of the dir list received
> | > thusfar).  Without that ^G, lynx will just sit there, showing a blank
> | > screen, and the (now static) "Transferred NNNNN bytes" message.
> |
> | What if that 2nd key is something else than ^G - like 'z' or '^L' or
> | down arrow?
> 
> They have no effect (other than say, ^Z, which does the expected thing,
> which BTW after fg'ing back to the lynx process, returns to the same
> "state" ... blank screen, except for the now static xfer counter in the
> statusline position).
> 
> Only a ^G at that point will initiate the on-screen rendering (with either
> "z" or ^G used to interrupt the xfer itself).

You should be able to substitute 'z' for either or both of the ^G's.
Are you *really* sure this isn't the case? :)

> 
> | (I never use ^G for anything except cancelling a prompt or line
> | editing - it seems weird to me to use it where 'z' should be used.)
> 
> Heh.  IIRC, a ^G has always interrupted an access attempt (or actual data
> xfer) for me.  That includes aborting an access attempt to an apparently
> "slow" or "hung" link.
> 
> This behavior goes back to at least 2.8.1rel.1, and probably earlier.

Yes, it seems ^G has the same effect in HTCheckForInterrupt() as 'z', and
this has been the case for a long time.

> Which I suppose is the reason that I've never understood the rationale for
> adding the NSL/"z" network INTERRUPT code.  Guess I've just always assumed
> that the ^G method was an inbuilt emacs'ism, which worked on my particular
> platform, but maybe wasn't doing "the whole job" on other OS's, etc (hence
> the need for the NSL/"z" code).

But there is no NSL/"z" code!  The interruptability of NSL_FORK works by
calling HTCheckForInterrupt(), for which ^G has the same effect as 'z',
it's just that people usually talk about it in terms of 'z' and not ^G.
Well at least, that last sentence is what *should* be the case IMO, only
now you claim it isn't since you say 'z' does not act like ^G here...

> I dunno which key I use more frequently ("z" or ^G) to halt a network access
> attempt, and/or an xfer in progress, as both (seemingly) do exactly the same
> thing (for me).  Guess it's about a 50/50 split, depending of which key is
> closest to my left index finger at the time (yes ... I "hunt and peck" ...
> always have).
> 
> 
> | What does the lynx process do while it just 'sits there', is it using
> | CPU time (some loop), does it still have network sockets open?
> 
> It's in S(leep) state, and not *really* using any CPU to speak of (I left
> a lynx in that state for ~6+ hours, and it used 0.7 CPU secs during that
> period ... so no, no "hang loop").
> 
> I don't *think* it has a socket open, though FreeBSD's netstat(1) command
> does not make it easy to tell.
> 
  [ snipped TRACE ]
> 
> 
> | Is this only with -partial enabled?
> 
> Well "partial" is defaulted to normally on, and adding "-partial" to the
> command line should toggle it off, I believe.  I get the same results
> with or w/o "-partial".

Yes, it should be a toggle, but -partial=off should now work (as for other
toggles) to force it off.

> Haven't tried a build with "partial" compiled out (nor with NSL disabled,
> for that matter).  A couple things to try and isolate the behavior(s), I
> suppose ... maybe later on today ...

I can't imagine how NSL_FORK would play a role here, since everything is
happening long after the name lookup.

> | If not, it may have something to do with the following (end of 
> read_directory
> | in HTFTP.c):
> 
> | Maybe 'the response(NIL) below hangs' is true not only for those
> | server types, but also for others.  I added that NETCLOSE a long
> | time ago, when testing with those weird servers seemed to show
> | that they needed it, but didn't add it for cases I didn't know
> | about.  It should probably also be done if WasInterrupted is true
> | at that point (please test, I don't want to start loading
> | multimegabyte directory listings now..).
> 
> Another thing I'll look into, if any of the above information doesn't add
> anything to your speculations (as I expect it won't).

Your trace looks entirely consistent with it.  (The first interruption
should be visible [if it leaves any trace in TRACE] much earlier in
the log, before the text and anchor dumps.)

In fact, after thinking about it more, it seems more obvious to me now
that this is exactly what has to happen.  We haven't closed the data
socket at that point, we just stopped reading from it.  So the remote
side just sees a stalled data connection if there are more outstanding
data we haven't read than would fill up TCP windows and buffers.  So
it just waits to be allowed to send more data.  But we're not opening
the window for that, instead we wait for someting to happen on the
control socket, so we have deadlock.

The only things that don't fit are
 1.) 'z' doesn't do the same as ^G.
     If you canfirm that, it might be some kind of slang thing.
 2.) you think it has no sockets open (but you are not sure).
     I think there should be two open.


  Klaus