Hi, Wow! Thanks for all the feedback (public and private) on that one! Looks like we're locking that nasty bug in our crosshair which is great considering it's responsible for 10% of all crashers. Thanks a lot to Thickbrick who identified the libcurl known issue.
I'm going to try to summarize the proposed actions and give my view on each: - Use LLCurlEasyRequest only (drop LLCurlRequest): that could be OK for the map but, considering we want to use http for all textures eventually, we can't really go with a system that open and close connections like crazy. Could be a disaster perf wise. We should consider this bug as an opportunity to fix LLCurlRequest for good and help the viewer in general, beyond the map. I'm sure Steve and Bao will thank us later (not to mention the residents... :) ) - Work around the bug in LLCurlRequest: considering that we do support threads, we could actually run all curl code in its own thread using the easy interface (synchronous) only. I'm not a big fan of that solution either as we do have quite a bit of requests going on at the same time. My instrumentation of the code shows that we typically run 6 simultaneous requests at the beginning of a session (using LLCurlEasyRequest though) and up to 12 simultaneous request while browsing the map. We don't really want to queue 12 requests I think. If we use http fetch for all textures of a scene, I'm quite sure it's going to be much more simultaneous requests. - Update libculr to a more recent version and see if that fixes the problem: as pointed to by Thickbrick, the trace pattern we have seems to be a known existing bug so that's likely not enough for a solution. - Use the c-ares resolver for libcurl (proposed by Tofu): that seems to be the more promising and general solution, making no compromise and keeping the wrapping llcurl.cpp code simple, multiplatform and general. Unless someone comes up with a horror story of why we shouldn't do that, I'll be working with Tofu next week to get that into Snowglobe. Thanks again to all proposing solutions and commenting on this thread. That feels good to see the community work :) Cheers, - Merov On Jul 3, 2009, at 9:49 AM, Tofu Linden wrote: > Thickbrick Sleaford wrote: >> There is also an unfixed windows-only crash in libcurl: >> >> http://curl.haxx.se/docs/knownbugs.html >>> 64. The threaded resolver used in libcurl on Windows has some kind >>> of race >>> problem when multiple simultanoes resolves are done, like with the >>> multi >>> interface transferring many files in parallell: >>> http://curl.haxx.se/mail/lib-2009-04/0028.html > > That's not good. > The good news is... the c-ares resolver option for libcurl works on > Windows (last I tried) so we could switch to that and dodge the cited > bug. There just hasn't been a point until now. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
