[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] DNS queries, blocking C calls, and non-file-descr
From: |
Chris Hanson |
Subject: |
Re: [MIT-Scheme-devel] DNS queries, blocking C calls, and non-file-descriptor events |
Date: |
Sun, 13 Aug 2006 02:35:45 -0400 |
User-agent: |
Thunderbird 1.5.0.5 (X11/20060812) |
Taylor R Campbell wrote:
> Name resolution is a bit annoying on Unix. [...] The only reliable way to
> resolve internet host names is by calling gethostbyname(3) or
> getaddrinfo(3), preferably the latter. Unfortunately, these block,
> making a simple FFI wrapper around them undesirable.
I am not sure why the scalability of this is important. Are you
generating many DNS requests in a short time? Or are you just trying to
build the best thing you can, and that's bothering you?
Often in these cases I optimize for particular systems I care about, and
don't put too much effort into the general case. Here, you could use
the getaddrinfo_a(3) call (a GNU extension using posix real-time
signals) to work around the problem. It's undocumented, as far as I can
see, but extends getaddrinfo(3) adding asynchronous signalling of lookup
completion. That could help with GNU systems (mostly what I care about
these days), and maybe there are other tricks for other systems.
I don't know if this will help. My recollection of the similar case of
processing incoming network packets from multiple connections is that,
although there are several available solutions (polling, select, async
i/o, threading, and maybe others), the performance of any given solution
is unobvious, probably counter-intuitive, and highly system-specific.
So asynchronous delivery may actually perform _worse_ than something you
think is awful.