Ethereal-dev: Re: [Ethereal-dev] ethereal 0.10.3 hangs on Redhat Linux 9 (glibc 2.3.2)
craig said:
> i guess i assumed that the author of the comment was also the author of
> that module, not the author of ethereal.
There's not even a unique referent for "the author of that module" -
several of us have contributed to the name resolution code.
> actually, i wasn't suggesting that the code be ripped out entirely;
> i realize that glibc based systems are only a subset, perhaps a small
> subset, of the OS platforms that ethereal runs on. but for glibc based
> systems it seems to be a "bad idea".
It's also a bad idea for OS X, as per the comment - and other OSes where
name resolution involves communicating in a stateful fashion with a daemon
process might have similar problems - and it doesn't work at all on
Windows.
So we have, for OSes where it doesn't work (either because it's unsafe to
longjmp out of the call from a signal handler or because it's more work to
make it work and it *still* might be unsafe, e.g. if whatever "notify me
asynchronously after this many seconds elapses" mechanism Windows has
would deliver the notification in another thread):
Windows OT (95, 98, Me) and NT (NT 4.0, W2K, WXP, W2K3);
recent versions of at least some Linux distribtions;
OS X.
I'd be willing to bet that covers a significant number of machines on
which people'd run Ethereal....
Given that tcpdump got rid of the alarm/longjmp back in late 2001, and I
haven't heard much in the way of complaints, it might be OK for us to do
so as well - although we have a lot more UI to lock up if the resolution
hangs forever, so maybe there's still *some* reason to keep it; I might be
tempted to just forcibly undefine AVOID_DNS_TIMEOUT for the next release,
and see whether we get a lot of "it hangs!" complaints.
