On Fri, 15 Dec 2006, Armel Asselin wrote:

> so maybe what I called the state FTP_REUSE (finishing send, then finishing
> receive) would be put into curl_ftp_done? is it possible to still do
> non-blocking stuff in the curl_ftp_done? because i would prefer to avoid any
> wait during this period (parallel downloads would suffer).

Everything is possible. The question is only how much effort that's
required... But the short answer is that no, there's no current support for
doing the DONE operation non-blocking so you'd have quite some work ahead of
you to make it so!

> would this totally different direction be meaningful to you?

> - we could have a CURLOPT_CANCEL which could be set to 1 while a CURL easy
> handle is running, in this case, the current request would get ended as fast
> as possible. we could have several code here such as: 'cancel nicely' (what
> we are trying to do), 'cancel hardly' (would just end marking connection
> invalid, doing nothing intelligent but ultra-fast).

Before even considering adding this option and the various ways of dealing
with them, I think we should consider if there's any interest from users in
it. Remember that you are the first person who brought this issue up, so this
is not a big issue to people.

I say we fix the immdiate problem (the waiting for the response when there's
none about to come) when you remove the handle prematurely. Which I believe is
the one you call 'cancel hardly' above.

> - remove the easy from the multi while in do phase, would do only the hard
> cancellation, removing the need from doing intelligent things in 'done'.

This situation only happens when the multi interface is used, I believe.

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