On Thu, 17 Jan 2008, Dmitry Kurochkin wrote:

> I know. I sent the patch from work. And I am behind http proxy which
> restricts connections to 80 and 443 ports only. So I am not able to connect
> to CVS.

*cough* http://daniel.haxx.se/docs/sshproxy.html :-)

>> It marks the handle as wanted-to-be-removed but doesn't actually do it now
>> but leaves it to be removed later when it can be removed without causing as
>> much problems.
>
> So curl_multi_remove_handle() returns CURLM_OK but in fact continues to use
> easy handle. But documentation says:
>
> Removing a handle while being used, will effectively halt all transfers in
> progress.
>
> Moreover of user does curl_easy_cleanup() on the handle we get a major
> problem in Curl_close()... I think we should either return error code from
> curl_multi_remove_handle() or really close connection and remove handle.

Thinking about this issue further, I can only agree with you. The current way
is deeply confusing and will indeed cause funny unexpected things (that aren't
documented). I think it is wrong.

Just returning an error is also not really a satisfying behaviour, since the
application clearly wanted to remove the handle and it'll be messy for the
application to deal with the error in general and with this error in
particular.

Thus, I think the only really sensible thing to do that won't be surprising to
the app and won't cause the app major headaches, is to kill the handle for
real (and break the pipeline).

We can possibly consider adding a curl_easy_getinfo() option that can tell the
app if the particular easy handle is involved in a pipeline currently that
thus would break if the handle is removed, but I'm not sure any app would care
about such a one anyway.

Will you have a look at addressing this issue as well? (And yes, you're soon
to be labelled Mr Pipeline! ;-P)

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html