Hi Daniel,
I appreciate the response.

On Fri, Jun 11, 2010 at 09:08:06AM +0200, Daniel Stenberg wrote:
> On Wed, 9 Jun 2010, johansen_at_opensolaris.org wrote:
> >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.

Yes, the application is using pipelining. The handles do appear to be
part of a chain. I've re-compiled 7.20.1 with CTF, the debug symbols
that mdb(1) understands. This problem has popped up on a couple of
machines; I'm hopeful that I'll have a more detailed core-dump for
analysis soon.

I couldn't figure out why writechannel_inuse would be left as TRUE,
either. I wondered if addHandleToSendOrPendPipeline() should check if
the added handle gets moved to the head of the pipeline, like
checkPendPipeline() does, but I still can't imagine how a connection
might leave the pipeline and have writechannel_inuse remain TRUE.
I'll provide more details as soon as I have them.

> >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.

Thanks. I'll file a bug against my software to add support for this. I
noticed that the progress callback doesn't get invoked from the WAITDO
state. I'm assuming that it would be best to have the timeout monitoring
occur in the same thread of control that's calling Curl_multi_perform()?

Thanks for your help with this,

-j
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-06-11