[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] 2 Lynx "Bugs".

From: Thomas Dickey
Subject: Re: [Lynx-dev] 2 Lynx "Bugs".
Date: Wed, 09 Apr 2014 19:49:41 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Apr 08, 2014 at 11:34:26AM +0100, Ian Collier wrote:
> On Mon, Apr 07, 2014 at 08:29:54PM -0400, Thomas Dickey wrote:
> > I could test lynx from one of my local machines, but everything's
> > going through the same DNS.  (Some clues for how I could reproduce
> > the problem would be helpful).
> How about: edit resolv.conf and put a non-existent server (e.g.
> as the first nameserver.  In my experience this adds a delay of 7-10
> seconds during which Lynx can't be interrupted with z or ^G.  However,
> ^C does interrupt it (and exits Lynx).

That still doesn't get me there: lynx is behaving as I would expect.
Tested with both Debian 6 and FreeBSD 9.1

However, it occurs to me that one or more of the people on this thread
overlooked the fact that the NSL-fork feature (which provides the
interruptibility) has "always"(*) been not compiled-in by default:

  --enable-nsl-fork                     (define NSL_FORK)
        Disabled by default, this allows interruption of NSL requests,
        so that `z' will stop the `look-up' phase of a connection.

If it's compiled-in, then NSL_FORK will show up in the "lynxcompileopts:"
special page.

_After_ resolving DNS, there is as I pointed out, still a possible timeout
connecting to the actual page.  That's not interruptible, as I recall it.
Once _connected_, the process of downloading is interruptible - by polling
between reads from the source.

The last time I worked on this aspect of the code was in 2012, to fix the
problem where sites with multiple IP-addresses did not all succeed (due to
limited number of addresses passed back from the forked process).  Problems
in this might show up in the -trace file - however, the trace file doesn't
really show what's going on in the forked process.  A truss (with timestamps)
could show that.

On the other hand, it might be just a configuration problem as I suggested :-)

(*) since I added the configure option late in 1997

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]