Re: Nameserver calls - libesmtp problem?

On Fri, 22 June 12:06 Albrecht Dreß wrote:
| Am 21.06.2001 23:15:13 schrieb(en) Brian Stafford:
| > I use gethostbyname_r() in libESMTP since it is thread safe.
| Hmmm... I did not find a man page for it either in ix86/RedHat 7.0 or
| in LinuxPPC 2000... No idea how I can test this routine.

Use "info libc" and then scroll down and follow the link to
Fucntion Index.  From there you can get to gethostbyname_r

| Here at home I run LinuxPPC, and the glibc is /lib/
| (belonging to the package glibc-2.1.3-15f).

OK.  I presume glibc behaves the same on all platforms.  Who knows?

| > much like most other programs that use them do, i.e. trusting them
| > to do the Right Thing and not hard coding special cases like
| localhost.
| Agree. And gethostbyname *does* the right thing, or at least seems to
| do.

Yes, but it isn't thread-safe.  This means bad things will happen at

| > for other platforms indeterminate.  I figure the only safe strategy
| is to
| > run a name server on the local host or somewhere on the local
| network
| > and make sure applications use *only* stub resolvers.
| Well, I actually had the problem that Netscape seemed to call the
| nameserver
| in regular intervals for no good reason, thus initiating dial-ins.

Probably polling POP or IMAP servers.

| However,
| since I moved away from it to Opera and of course balsa (Netscape is
| crap anyway!), this was gone completely.

Don't you just *love* the inconsistency between apps?

| I am fine with the solution to just
| compile balsa without your lib,

I'd rather you used it.  I need bug reports if I'm going to make the
code stable.

| but IMHO we should at least find out what goes on there.

Agreed.  I don't see why my code should be penalised for using thread
safe code in a threaded program.

| > I will look into using one of the more modern resolver APIs.  The
| > lightweight resolver library that comes with the bind 9 distro or
| > the IPv6 safe functions (getipnodebyname or something like that
| > I think) come to mind.  Both of these alternatives are thread safe,
| > so perhaps the main Balsa code should use them too.
| I still have the bind 8.2.2 package installed here. But that might be
| a good idea, at least it's worth a try...

I think that whatever solution I choose must be the same as that
used by other applications, otherwise you'll get the inconsistency
again.  The one thing I cannot do is to use functions that are
not thread safe; for example, it isn't enough to protect gethostbyname
with a mutex.


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