On Wed, 9 Jun 2010, [email protected] wrote:
From using DTrace, it looks like the library has two active handles. Calls to curl_multi_perform return a running_handles count of 2.
That counter is indeed what libcurl counts so that should be reliable in all circumstances.
When I grab the Curl_one_easy out of the call to multi_runsingle(), it appears that the remaining handles are stuck in CURLM_STATE_WAITDO and CURLM_STATE_INIT, although the init state may be bogus.
I can't see any reasonable explanation to how a handle would get stuck in CURLM_STATE_INIT.
The easy handles are configured to have a connect timeout and a low speed timeout, but neither of these has triggered to boot the handle out of being stuck in this state. Can anyone postulate a situation where writechannel_inuse should be False, but was somehow left as True?
Are you using pipelining? Is one or two of these handles possibly part of such a pipelining chain?
But no, I don't know how writechannel_inuse wronly would be left TRUE.
On a related note, is there any other defensive programming I could have done to avoid this scenario? It doesn't look like any of the timeouts are checked in this state. Should handles remain in this multi state indefinitely?
We have a general timeout problem with the multi interface as described in known_bug #62. We should have the handles all be subject to timeouts in all states but they aren't yet so.
The defensive programming you can do for now is to monitor the timeout yourself and when a handle has stayed in the multi handle "too long" you pull it out of there again.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
