>>>> /* 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.
OK so could we tell to Curl_done what is the current multi state? or that
Curl_done happens prematurely (multri state type seems to be local to
multi.c though)
from what i understand this cancellation stuff could profit any protocol,
and as for all protocols the multi state will actually tell if the removal
happened earlier than expected. and this information is already maintained
(correctly) in the multi, if we try to 'know that Curl_done happened
prematurely per protocol' curl would have to maintain a state variable, very
similar to the multi state in each protocol specific structure.

>> 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.
yes why not it does not seem to interfer in any way.

>> 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.
yes I previously wrote the ABOR question is secondary. we must first be able
to cancel correctly a request (which is not the case with current code).
then we'll try to handle the ABOR command. note that issuing a ABOR command
on a connection which handled a previously cancelled request, whatever the
connection state, is perfectly ok (if nothing is to be aborted curl just get
an error meaning 'nothing to break', else it actually breaks, and whatever
the case, the connection is right and all of this is still far better than
fully re-connecting, re-negotiating SSL stuff...).

>> - 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?
what I mean is that ABOR is not issued to _cancel_. it is issued to
_recover_. when you cancel a request, you just close everything as currently
(without all the timeouts stuff hanging for one minute though).
the ABOR command is issued, if and only if, you try to reuse this
connection.

Armel
Received on 2006-12-06