On Wed, 9 Jun 2010, johansen_at_opensolaris.org 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