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
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
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
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.
--
/
"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);
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;
}
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
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
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
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"
Hello all,
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" would not close properly the
13 matches
Mail list logo