[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev z (was Re: Timeout parameter?)
From: |
Bela Lubkin |
Subject: |
Re: lynx-dev z (was Re: Timeout parameter?) |
Date: |
Tue, 1 Sep 1998 17:47:39 -0700 |
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<
- Re: lynx-dev z (was Re: Timeout parameter?),
Bela Lubkin <=