Re: Infinite loop in Curl_splay
Date: Fri, 1 Jul 2011 22:48:34 +0200 (CEST)
On Fri, 1 Jul 2011, Christian Hägele wrote:
>> We should figure it out for sure and add something about it to the
> After I changed my code so that curl_multi_add_handle is not called from
> within curl_multi_socket_action the infinite loop did not occur again. I
> didn't debug through the code in detail but adding a easy-handle to a multi-
> handle inserts a new timeout in the splay-tree and might change its internal
> structure while the same thread on another (lower) frame in the callstack is
> currently traversing it. (Again I did not reproduce it on intention yet)
Right, I was thinking about that risk when you asked but a quick glance didn't
make any code immdiately stand out to me. I guess your empirical experiment
still indicates that there is such code.
> This can be a pitfall for many developers, because it seems to work nice
> most of the time and only in very rare special cases causes a problem.
You're the first person ever who have reported this problem or at least
clarified it enough to make us conclude the reason, so I wouldn't quite say
that it affects _many_ developers. But yes, it causes some rather weird
problems that can be hard to track down.
> Some hint in the documentation would be nice
Have you given any thoughts on where in the docs? Do you mean in some general
hints section for how to write callbacks and what not to do in them?
> and better handling within curl would be even nicer.
Yes, I could imagine that we invent a way that makes recursively calling
libcurl functions fail immediately with a clear error code. It would at least
make it clear, and it would make us have to consider which (if any) functions
we should allow to get used from within callbacks. I'm sure people already use
curl_easy_getinfo() at least.
Anyone wants to work on it?
-- / daniel.haxx.se
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2011-07-01