I sort of also want to understand the issues here as I'm working on integration of libcurl into our product (client-side app). As far as I can tell there is no way to avoid at least some blocking when doing network I/O and relying on select/poll to detect data availability and using non-0 timeout values, which is how libcurl seems to be implemented. With that in mind it is probably not a very good idea to call into libcurl on the same thread that updates the UI. If this is what is happening in your case you may want to consider to have a dedicated thread for network I/O that fires notifications to UI to update when data is actually available, this should help to avoid freezing the UI as the UI thread will never block on select/poll (and possibly other things).

-Vlad

> Date: Fri, 10 Dec 2010 10:42:11 +0200
> Subject: Re: Locking and multi on multiple connections.
> From: arxeio_at_gmail.com
> To: curl-library_at_cool.haxx.se
>
> On Fri, Dec 10, 2010 at 10:05 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> > what you're doing and when these blocks occur and how long they are
>
> The premise is basic. Cycle through the same easier with new available
> URLs and find available ones. Call multi perform every cycle of the
> app. It does work pretty well 99% of the time. But rarely, it will
> block for about 0.4 seconds at most. Since it's critical to the
> experience of the app to never block, it's important.
>
> I haven't profiled it yet but I suspect it'll block on multi perform
> again. The rest are common string operations on C, unless it blocks on
> inserting and removing easies from the multi, or on extracting info
> from it.
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
                                               

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-12-10