On Fri, Oct 21, 2016 at 11:13:04AM +0200, Daniel Stenberg wrote:
> I propose this change (see attachment) that "forces" the connections to get
> marked for closure before tryign to do disconnect them, which should fix the
> problems we've now got reported three times.
>
> It isn't really a fix to
On Thu, 20 Oct 2016, Valentin David wrote:
How did you end up in this situation, is it reproducible? Are you using
Pipelining or HTTP/2 multiplexing?
No HTTP/2. But maybe some pipelining. Howerver I do not think it is used
when this happens. recv_pipe size is 1. I think the way it happens is
Sorry for answering late. I did not tweak my email filter after
subscribing.
On Tue, 2016-10-18 at 10:26 +0200, Daniel Stenberg wrote:
> Infinite loop sounds related to Dan F's post from two weeks ago:
> https://curl.haxx.se/mail/lib-2016-10/0011.html, but the triggering
> reason
> seems differe
On 10/18/2016 7:16 PM, Miloš Ljumović wrote:
"Handles. You must never share the same handle in multiple threads.
You can pass the handles around among threads, but you must never use
a single handle from more than one thread at any given time."
I'm not sharing handles. Take a look at ServerProc.
On Wed, 19 Oct 2016, Miloš Ljumović wrote:
Try the program (in the attachment) and we'll continue discussion.
One quick note (its getting late here): this isn't using pipelning, it enables
HTTP/2 multiplexing.
--
/ daniel.haxx.se
"Your example is not complete, but based on what you have provided here
is what you should look at:"
Yes - as I said, pseudo code. It was meant to give you an idea.
"Strings passed to libcurl as 'char *' arguments, are copied by the
library" [1] with the exception of CURLOPT_POSTFIELDS."
This
On 10/18/2016 12:08 PM, Miloš Ljumović wrote:
// Here I have to use dynamic memory - strange, cause I saw
"strdup" in libcurl
char* szUrlBuffer = new char[1024]; // leak, needs upgrade
StringCchPrintf(szUrlBuffer, 1024, "%s%s", szAPNSAddress,
szDeviceToken);
curl_easy_setopt(hE
Here is the (pseudo) code:
long PushRequest(params ...)
{
CURL* hEasyHandle = 0;
Lock(); // EnterCriticalSection
{
// init easy handle.
hEasyHandle = curl_easy_init();
}
Unlock(); // LeaveCriticalSection
if (!hEasyHandle)
{
return -1;
}
I will debug it again and post the notes.
Miloš Ljumović
Operating system specialist
http://milos.expert.its.me
---
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
On Tue, 18 Oct 2016, Miloš Ljumović wrote:
Gets stuck. 7.51.0.
There is no 7.51.0 released yet, so then you must be using libcurl built
straight from git.
But yeah, it makes sense that the bug is still in the code even after 7.50.3
since there have been no attempts of fixing it yet.
Any
Gets stuck. 7.51.0.
What do you mean "don't top post"?
Miloš Ljumović
Operating system specialist
http://milos.expert.its.me
> On 18 Oct 2016, at 11:21, Daniel Stenberg wrote:
>
> On Tue, 18 Oct 2016, Miloš Ljumović wrote:
>
> Please don't top-post.
>
>> I have the same situation. I'm usin
On Tue, 18 Oct 2016, Miloš Ljumović wrote:
Please don't top-post.
I have the same situation. I'm using pipelining. But it's different
scenario.
You mean same as in it gets stuck or same as in still contains receivers in
recv_pipe ? Also on 7.50.3? (Not that I think we changed anything partic
I have the same situation. I'm using pipelining. But it's different scenario.
One thread does all multi_* calls while all other threads do easy_init &
multi_add/remove_handle protected by the critical section. Everything works
perfectly on 100 parallel threads but close_all_connections never retu
On Mon, 17 Oct 2016, Valentin David wrote:
When I upgraded cURL to version 7.50.3, I got some of my code to run into an
infinite loop when closing down the "multi". All "easy" are closed, but some
connections in the cache still contains receivers in the "recv_pipe".
Calling "Curl_disconnect" w
14 matches
Mail list logo