On Fri, 22 Mar 2002, Noel Byron wrote:

> First, I'm a little bit confused about the differnent lists. I thought the
> curl-users_at_lists.sourceforge.net is the new one:

We have many lists, and I understand if this is causing some confusion. Linus
already pointed this out. All up-to-date mailing list details are found here:
http://curl.haxx.se/mail/

The whole idea of having separate lists for separate areas, is to decrease
the amount of mails every single subscriber receives that is outside his or
hers interest.

> > If you define a good generic way, then there's no harm with starting to
> > add asynch name lookups on windows only.
>
> Platform independence is a big issue for me, too. But I have to admit, that
> I have no idea how to asynchronous DNS resolution with POSIX. Maybe the
> POSIX real time extensions could help.

My point, when I talked about a generic interface, is that you need to
encapsulate your functions so that libcurl can be written to use the
encapsulation layer, independent of the actual OS or how it does asych name
lookups.

Of course, knowledge about the most common ways to do asynchronous name
lookups will help us to decide on a good enough interface already from the
start.

I haven't really put any efforts into this subject myself yet, so I don't
have any bright ideas here at this point.

> Anyway, if we do async DNS in Windows we can't wait in select.

I was afraid of that.

> What do you think about encapsulating the select function for the user?

That is certainly doable. It would make the reversed of what
curl_multi_fdset() does today, so instead we offer a select()-replacement.
Yes, that would certainly work and I already like the idea!

Hm, no, correction, I like it a lot! ;-)

> while(CURLM_CALL_MULTI_PERFORM ==
> curl_multi_perform(multi_handle, &still_running));
>
> while(still_running) {
> // some user code
> int ret= curl_mulit_select(multi_handle, 1 /* timeout seconds */, 0 /*
> msecs */);

The curl_multi_select() would need to support the existing select()
functionality too, as the application may want to wait for a couple of its
own file descriptors...

> I don't know if that is very important at the moment...

Well, keeping these things in mind isn't bad, as it makes it less likely that
we add other things that would prevent us from implementing this in the
future.

Still, we can't fix everything at once, we need to take one area at a time
and make it work first. At least until we've got more people involved.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/