On Wed, 6 Dec 2006, Armel Asselin wrote:

>>> /* if we have a connection we must call Curl_done() here so that we
>>> don't leave a half-baked one around */
>>> if(easy->easy_conn)
>>> Curl_done(&easy->easy_conn, easy->result);

> maybe i was not clear, in fact the first step of the process is to know that
> we are cancelling, and testing for easy->state seems to be rather logical:
> if the removal happens whereas there is no error and in the middle of the
> process (i.e. state!=CURLM_STATE_COMPLETED), it just means that this is a
> cancellation.

Yes, I agree that we can use the multi state to figure out if the process is
completed or not, and thus if the Curl_done() call is a normal end-of-transfer
call or if it is called before the end.

But: I don't want to add a puplic error code to the list of errors just for
this cause. Also, I would assume that just because it is a cancel, it isn't
strictly the same thing as an ABOR required, since if you'd remove the handle
_very_ early in the process it would not yet had the chance to start a
transfer and thus no ABOR would be needed.

> up to there there is no question of ABOR handling and whatever. it is just
> 'being able to cancel' (not being able to reuse cleverly the connection):
> even if it breaks totally the connection, what it does currently, it is
> still cancellation. when we are OK on that,

Of course, if the control connection is fine it should be kept "alive" even
when a transfer gets cancelled.

Note: libcurl treats connections somewhat different since 7.16.0+. It now
shares the connection cache within the multi handle: when removing an easy
handle from a multi handle, the connection itself might be kept around to get
used by another easy handle.

> I may go further and try to handle CURLE_CANCELLED error (or whatever we
> choose) in FTP code (probably in Curl_FTP_done) to handle this better (by
> marking the connection as wanting an ABORT command and keeping it, rather
> than throwing it away as it does with just passing CURLE_CANCELLED).

Yes, if ctlvalid is TRUE then the connection should indeed be kept.

> - detecting cancellation (the above test seem ok, i.e.
> easy->state!=CURLM_STATE_COMPLETE && !result)

I don't think this is necessary.

> - signaling cancellation to the protocol (Curl_done(conn, CURLE_CANCELLED)
> seems OK also)

I don't think this is necessary. The FTP code itself should keep track of it
needing ABOR or not. It will offer the best possible control of it, since we
only really want to send ABOR when there is a data connection in use.

> - handle cancellation in the nicest way per protocol (not done yet, maybe
> even not as necessary as the two above steps because they at least signal to
> the Curl_done function that the current state is not OK and we don't want to
> wait for any result good or bad).

I don't quite follow you here. What do you mean with "we don't want to wait
for any result good or bad" ? What do we not want to wait for when we do what?

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