On Fri, Dec 10, 2010 at 7:54 PM, Vladimir Grishchenko <[email protected]> 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
