>> /* 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);
>>
>> these lines do not taken into account the CURLMState, i.e. if we are not
>> at CURM_STATE_COMPLETED and easy->result is OK, we are cancelling, so we
>> should not pass easy->result but some error (new one CURLE_CANCELLED?)
>
> I don't think we should overload that variable with another meaning. I
> think you should instead add a new variable within the FTP struct that
> keeps information whether you should use ABOR when the connection is
> cancelled.
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.
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, 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).

so three steps:
- detecting cancellation (the above test seem ok, i.e.
easy->state!=CURLM_STATE_COMPLETE && !result)
- signaling cancellation to the protocol (Curl_done(conn, CURLE_CANCELLED)
seems OK also)
- 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).

am I more clear?
Armel
Received on 2006-12-06