curl-library
Re: Blocking operations in curl multi?
Date: Wed, 16 Apr 2003 15:16:05 +0200 (CEST)
On Wed, 16 Apr 2003, Martin C. Martin wrote:
> I'm using curl's multi interface to keep my app responsive without having
> to spawn another thread. So, I never want my call to curl_multi_perform to
> take very long, i.e. I always want it non-blocking. Unfortunately, DNS
> resolution is blocking (as, I think, it has to be without spawning a thread
> itself). Well, I can do the DNS resolution myself and hand curl a URL with
> numbers in place of the domain name. But are there any other blocking
> operations in there? When it initiates a connection, does it wait until
> that either succeeds or fails before returning? Are there any other
> operations that might take more than, say, 50 msec (assuming only a modest
> amount of data. I'm doing streaming audio.)
[ A final mail before I take off for a long weekend. ]
50ms is of course all depending on what CPU and things you're using...
Yes, there are more places than the DNS lookup alone. FTP command sending and
response-reading are two places I can think of immediately.
I think there's something in the SSL connection phase as well.
Most things should not lock up at all though but return as fast as possible,
with or without data.
We need a good audit to find and fix all those places. It is very easy to
say, but some of these are truly tricky to fix.
> Any chance of DNS resolution being done non-blocking?
Yes. As has been mentioned before here, we want to add that capability.
Currently, the way to that is named libdenise => http://libdenise.sf.net/ and
it is not ready for inclusion yet. We welcome all help we can get in that
area.
> This would probably involve curl_multi_perform() spawning a thread to do
> the actual DNS resolution, which would be OS specific, but that's not the
> end of the world...
We have discussed adding a callback/hook system to libcurl that allow users
to "plugin" their favourite asynch DNS system, so if you get that done you
can spawn threads or anything you want without disturbing other libcurlers.
Personally, I prefer a solid library implementation that works for most
platforms.
-- Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sfReceived on 2003-04-16