<div dir="ltr">hi mike,<br>The ncurl port is not yet in the official builds. meanwhile how do you suggest to fix this in the current baseline.<br><br>one of the changes that does help is to periodically cleanup the multihandle when the running job count drops to 0 and recreate on the next request (this is just a temporary fix till we find the real issue in curl)<br>
<br>i have few comments on the ncurl patch: <a href="https://bugs.webkit.org/show_bug.cgi?id=17972">https://bugs.webkit.org/show_bug.cgi?id=17972</a><br>- is it better than the current timer driven behavior, since the glib main loop polls the fds faster if its free- but thats seems to be a small gain since the timeout is very small<br>
- in the current implementation curl_multi_perform may block if theres lots of data queued up on multiple handles, but that can be easily mitigated by returning frequently from curl_multi_perform<br>- what about doing select in separate thread as glibcurl does. i think this is safe as perform happens in the main thread.<br>
<br>thanks,<br>Zaheer<br><br><div class="gmail_quote">On Wed, Sep 10, 2008 at 8:40 PM, Mike Emmel <span dir="ltr">&lt;<a href="mailto:mike.emmel@gmail.com">mike.emmel@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Look I had to change to one multi handle per handle basically just and<br>
asynchronous handle to get everything to clean up.<br>
Its a significant refactoring and better design.<br>
<br>
What it points to on the curl side is the need for and asynchronous<br>
simple handle.<br>
<br>
Also polling was removed as much as possible curl does not send decent<br>
time outs if it has real work<br>
to perform so this is still a issue. However open file handles are<br>
handled in the event loop select.<br>
<br>
Curl needs to be extended to have the concept of a work request and a<br>
longer term watch timeout.<br>
<br>
So in my opinion the issues are fixed at least to the extent possible<br>
without help from the curl team.<br>
<div><div></div><div class="Wj3C7c"><br>
On Wed, Sep 10, 2008 at 7:53 AM, zaheer ahmad &lt;<a href="mailto:zaheer.mot@gmail.com">zaheer.mot@gmail.com</a>&gt; wrote:<br>
&gt; hi,<br>
&gt; The fix only helps little as we see the bigger leaks in curl. feedback from<br>
&gt; curl experts suggests that this design is correct.. let me know if you are<br>
&gt; aware of this issue<br>
&gt;<br>
&gt; == here&#39;s the mail snapshot.<br>
&gt; we are seeing big leaks in curl (Curl_connect - 600-800k and Curl_open -<br>
&gt; ~200k) when we browse through as little as few websites. This values<br>
&gt; keep increasing as we browse more sites.<br>
&gt;<br>
&gt; heres the high level logic of webkit=curl interaction<br>
&gt; 1- create a multi handle at the start of program<br>
&gt; 2- keep creating easy handles for each request<br>
&gt; 3- when request is done remove it from multi handle and clean up the<br>
&gt; handle<br>
&gt; 4- multi handle is never released (stays till the end of program)<br>
&gt;<br>
&gt; This design assumes that multi handle has a bounded memory usage as we<br>
&gt; keep adding and removing easy handles, but that seems to be not true<br>
&gt; with the leaks.<br>
&gt; ==<br>
&gt;<br>
&gt;<br>
&gt;&gt;&gt; Now I just started to use valgrind to find other memory leaks, so this<br>
&gt; and other issues should be hopefully fixed soon.<br>
&gt;<br>
&gt; these are not traditional memory leaks, you are holding on to things longer<br>
&gt; than you should, so they are more functional leaks. Does valgrind help in<br>
&gt; that too?<br>
&gt;<br>
&gt; thanks,<br>
&gt; Zaheer<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Sep 10, 2008 at 8:02 PM, Marco Barisione<br>
&gt; &lt;<a href="mailto:marco.barisione@collabora.co.uk">marco.barisione@collabora.co.uk</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Il giorno mer, 10/09/2008 alle 07.22 -0700, Mike Emmel ha scritto:<br>
&gt;&gt; &gt; This leak is fixed in the ncurl port.<br>
&gt;&gt;<br>
&gt;&gt; Is it possible to backport the fix?<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Marco Barisione<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; webkit-dev mailing list<br>
&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
&gt;&gt; <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; webkit-dev mailing list<br>
&gt; <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
&gt; <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>