[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev partial not working on ftp:// url's (?)
From: |
Kim DeVaughn |
Subject: |
Re: lynx-dev partial not working on ftp:// url's (?) |
Date: |
Wed, 21 Jul 1999 09:57:17 -0600 |
On Wed, Jul 21, 1999, Klaus Weide (address@hidden) said:
|
| > | 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? :)
Heh. Guess I missed trying a "z" as the 2nd key (though I thought I had).
Indeed, it ("z") *does* clear the "hang" condition, and allows the rendering
of the (interrupted) xfer to proceed.
So you're quite right ... "z" and ^G are equivalent, in that situation.
| > 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.
And it (partial) makes no difference, either on or 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.
I didn't look at the code ... I just thought the "z" command, and NSL_FORK
were "coupled".
| > | 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..).
| 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.)
Hmmm. I couldn't find anything explicit for it (the 1st interruption) in
the log. Specifically, there's no indication where it switches from the
ctrace lines like:
>HTFTP: Line in alt is -rw-rw-r-- 1 88 8 841 Mar 20 1996
>alt.aus.bonehead.jimo-ngygook.bulletsdtopper.poofter.Z
>Adding file to BTree: alt.aus.bonehead.jimo-ngygook.bulletsdtopper.poofter.Z
over to lines like:
>GridText: Change to style Preformatted
>GridText: split_line(0 [now:19]) called
>HTML:begin_element[0]: adding style to stack - Preformatted
>new Anchor 0x17d460 named `' is child of 0x156400
>Entered HTAnchor_findChildAndLink
>HTParse: aName:alt/alt.*.Z relatedName:ftp://ftp.isc.org/usenet/control/alt
>>2
>HTParse: result:ftp://ftp.isc.org/usenet/control/alt/alt.*.Z
>HTParse: aName:ftp://ftp.isc.org/usenet/control/alt/alt.*.Z relatedName:
>HTParse: result:
>Entered HTAnchor_findAddress
>New anchor 0x156f00 has hash 33 and address
>`ftp://ftp.isc.org/usenet/control/alt/alt.*.Z'
>Linking anchor 0x17d460 to anchor 0x156f00
>HText_endAnchor: number:2 link_type:1
or from those, to lines like:
>HText_endAnchor: number:912 link_type:1
>GridText: split_line(0 [now:70]) called
>HTML:end_element[0]: Popped style off stack - Normal
>GridText: Change to style Normal
>GridText: split_line(0 [now:0]) called
>Gridtext: Entering HText_endAppend
>GridText: split_line(0 [now:0]) called
>GridText: Removing bottom blank line:
>GridText: New bottom line:
>GridText: Removing bottom blank line:
>GridText: New bottom line:
>GridText: Removing bottom blank line:
>GridText: New bottom line: Aug 30 1997 UNIX Compressed
>[912]^Ealt.<EF><AE>$.<A9>h<FC><AE><A9>h.<F8>m<F8>L<EB><FF><A9><AE><FC><EB>.Z^F
> 2Kb
>Gridtext: Entering HText_trimHightext (final)
>Gridtext: Anchor found on line:3 col:3 [1] ext:15
>anchor text: '[1]^EUp to control^F'
>GridText: add link on line 3 col 6 [1] in HText_trimHightext
>Gridtext: Anchor found on line:4 col:34 [2] ext:9
>anchor text: 'Oct 8 1997 UNIX Compressed [2]^Ealt.*.Z^F 1Kb'
>GridText: add link on line 4 col 34 [2] in HText_trimHightext
which are the lind of lines that the trace ends with (when the 1st ^G/z has
been issued (but before the 2nd such cmd is issued).
| 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.
Nope, they do the same thing (see above).
| 2.) you think it has no sockets open (but you are not sure).
| I think there should be two open.
Seems like it (per fstat(1) after the 1st ^G/z):
>USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
>kimdv lynx 1735 wd /users/u2 445445 drwx------ 2560 r
>kimdv lynx 1735 text /users/u2 361549 -rwxr-xr-x 466128 r
>kimdv lynx 1735 0 / 16113 crw------- ttyP5 rw
>kimdv lynx 1735 1 / 16113 crw------- ttyP5 rw
>kimdv lynx 1735 2 / 16113 crw------- ttyP5 rw
>kimdv lynx 1735 3* internet stream tcp f3605100
>kimdv lynx 1735 4* internet stream tcp f32d3400
>kimdv lynx 1735 5* internet stream tcp f3ec4300
whereas, after the 2nd ^G/z, we get:
>USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
>kimdv lynx 1735 wd /users/u2 445445 drwx------ 2560 r
>kimdv lynx 1735 text /users/u2 361549 -rwxr-xr-x 466128 r
>kimdv lynx 1735 0 / 16113 crw------- ttyP5 rw
>kimdv lynx 1735 1 / 16113 crw------- ttyP5 rw
>kimdv lynx 1735 2 / 16113 crw------- ttyP5 rw
>kimdv lynx 1735 4* internet stream tcp f32d3400
Though again, netstat(1) shows no sockets related to "isc.org", my uid,
or lynx's pid.
In summary, your analysis seems to be correct (as usual) ...
/kim