On 8/25/06, daniel.haxx / gmail.com <daniel.haxx / gmail.com> wrote:
> Francis Cianfrocca wrote:
>
> > > > libcurl offers an asynchronous API that does the name resolving
> > > > asynchronously if you've built libcurl to do so.
> > >
> > > Does it use the native getaddrinfo()?  The problem I've had on FreeBSD
> > > is that getaddrinfo() will block.
>
> > Does it matter whether it blocks or not? Ruby can't schedule its green
> > threads while you're inside a system-library call unless the call
> > knows about Ruby's scheduler (which it doesn't). Right?
>
> You _could_ read up on the libcurl details in the libcurl docs, but
> then what fun would that be? Let's continue making assumptions like
> this...
>
> No, it is _not_ asynchronous inside a system call and it is _not_ using
> the native getaddrinfo() for asynchronous name resolves.
>
>
>

You may have misunderstood me. Even if libcurl or anything else
resolves names "asynchronously" (which can mean more than one thing),
then does that make it faster on a per-resolution basis, or just more
concurrent? If the former, then I'll read your code to see how you did
it. If the latter, then doesn't a Ruby program need to be written in a
special way in order to benefit from the concurrency?