On Fri, Dec 10, 2010 at 7:54 PM, Vladimir Grishchenko
<vladgri_at_hotmail.com> wrote:
>
> 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

The first version I had written were threads with easies. Then to
avoid some multiplatform issues with pthreads I made a single threaded
multi. I suppose a 'hybrid', threaded+multi would the best since it
would both be multithreaded and recycle connections (especially if the
contacting domain does not change).

Though, it worries me in case the pthreaded curl had issues quite
generic on the libraries so if there are no serious issues with the
single threaded multi, I may not change it.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-12-11