Re: lynx-dev z (was Re: Timeout parameter?)

[Bela Lubkin]

brian j. pardy wrote:

> IIRC, gethost[by]name() (whichever lynx uses, no source in front of me) 
> blocks when looking up a hostname, making it impossible to interrupt it.
> That's why forking it away allows an interrupt.

gethostbyname() comes from the BIND resolver library [dunno about under
Windows or VMS].  In older 4.8/4.9 versions of the library, there are
timeout parameters which can be modified.  Unfortunately, they're in an
internal structure which isn't documented or intended to be exposed.
(I'm talking about struct __res_state _res, fields "retrans" and
"retry".)  I don't know whether this situation has changed in the
current BIND 8.x versions.

Lynx *could* access these variables in an attempt to control name lookup
behavior.  The code would have to be #ifdef'd a lot, with lots of
interaction with configure, to deal with different structure names in
different releases (res vs. _res, etc.)

Alternatively, the NSL_FORK code could easily enforce a time limit; in
fact, the current code loops forever: while (cstat <= 0) { /* bunch of
stuff */ sleep(1); }, WWW/Library/Implementation/HTTCP.c:HTParseInet().
That should be fixed.  Keep a loop count and kill the child after too
many loops, where "too many" defaults to something reasonable like 60
seconds.  Let the user specify that loop count.

> > (2) how difficult would it be to add a time-out option as JE requested,
> >     in  lynx.cfg  & the other usual places, esp for off-line use?
> 
> Don't know that.

Implementation described above.

It may also be possible to implement a timeout around non-forked
lookups, using alarm().  I think the resolver itself uses select() to
implement its timeout, so alarm() is still available.

> > (3) why do we have to rely on a configure switch (of all things)?
> 
> I'd rather see it as an option instead of as a configure switch as well.

Some of the systems Lynx works on do not support the underlying
functions used by NSL_FORK.  I don't think Windows has fork() and
exec().  Of course it has functions that have similar effects (which
have recently been used to add similar functionality to the Windows
version of Lynx).

I think there was also originally some concern about whether lookup
interruption would work even on systems that support the necessary
functions.

Tom: maybe it's time to switch NSL_FORK on by default, for Unix targets.
Looks like NSL_FORK depends on fork(), waitpid(), _exit().  If any of
those are called elsewhere in the code, outside of #ifdefs, then we know
they're broadly supported.  I see that fork() is called by LYExecv() in
src/LYLocal.c, outside of the #ifdef DIRED_SUPPORT even though it's only
used by functions inside it.  So fork() at least links on all the Unix
targets...  waitpid() is protected there by an #ifdef HAVE_WAITPID.  And
I guess _exit() is probably universal on Unix systems.  So I think it'll
work.

Are there any readers who know about and deliberately do not turn on
NSL_FORK?

There *is* an overhead -- the process forks.  Any "modern" Unix system
(using virtual memory as good as 4.2BSD's or better, i.e.  dating back
at least 15 years) should take only a small memory hit...

>Bela<