From: Ken Raeburn <raeburn@raeburn.org>
Subject: Re: Code review for thread safeness
Date: Sat, 18 Jun 2005 01:03:06 -0400 [thread overview]
Message-ID: <a744a7a7756ce04d458f43906c02297f@raeburn.org> (raw)
In-Reply-To: <87ll8w3i04.fsf@ivanova.rotty.yi.org>
Oh, how annoying. In going back over some old email messages in my
way-too-full mailbox, I just noticed these replies to my message that
I'd never read! I apologize for not replying before.
On Mar 9, 2005, at 11:23, Andreas Rottmann wrote:
> Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>> Ken Raeburn <raeburn@raeburn.org> writes:
>>> If at all possible, this code should be switched to use get*by*_r, or
>>> in the gethostby* cases, perhaps getaddrinfo and getnameinfo.
>> Yes, definitely. Could you help with that?
> FWIW, I just stole some code from GNet (http://www.gnetlibrary.org)
> for another project. You might want to have a glance at how they do
> this stuff, since it seems there are different flavours of
> gethostbyname_r (glibc, HPUX, Solaris). The relevant code is in
> inetaddr.c and configure.ac (detection). GNet is LGPL-licenced BTW.
I've spent some time dealing with getaddrinfo/gethostbyname_r/etc for
work, and found this to be a rather annoying morass to dive into.
There are at least three variants of gethostbyname_r among the systems
I'm supporting, and some (even modern systems like NetBSD and Mac OS X)
don't have it at all; almost all of the systems have getaddrinfo,
though different implementations have different minor bugs. I've also
gone through writing code to determine which flavors of which routines
are available, and implementing a wrapper to deal with all the
variants.
In the long term, I think getaddrinfo is what we want to be using. But
for the short term, hacking up the gethostby* routines to use the _r
versions when they're available shouldn't be that hard. I'll look into
it.
(Oh, eww, we've got 'gethostent' support too. Bleah. Well, glibc at
least seems to have a gethostent_r...)
Ken
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2005-06-18 5:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-07 22:04 Code review for thread safeness Marius Vollmer
2005-03-07 22:36 ` Kevin Ryde
2005-03-08 1:18 ` Marius Vollmer
2005-03-08 3:18 ` Ken Raeburn
2005-03-09 14:48 ` Marius Vollmer
2005-03-09 16:23 ` Andreas Rottmann
2005-06-18 5:03 ` Ken Raeburn [this message]
2005-12-06 18:58 ` Marius Vollmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a744a7a7756ce04d458f43906c02297f@raeburn.org \
--to=raeburn@raeburn.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).