>> [I still use curl - 7.15.6 as of cvs head 2006/08/21]
>
> I wouldn't advice hanging on to that.
hum, I do not have any problem with what I do from it, so unless I need/use
new features, I prefer keep that.

>> In fact I'm on another problem, the removal of a curl handle from a multi
>> is understood as being a removal '_after_ success or error'...
>
> No, that's not "understood". It may be so that the code currently only
> gracefully deals with those situations, but it is not the intention.
OK

>> the Curl_ftp_done function expects to have stuff either in error or in
>> good state. but in the case of a 'cancel' which may happen at any time,
>> the transfer is both in success and in a fairly transient state so that
>> Curl_ftp_done _hangs_ one minute before going on.
>
> So it should be fixed!
>
>> could we have something to tell "please cancel this operation"? (on
>> option for example which notes that on Curl_???_done libcurl should trash
>> everything as fast a possible). this option would be set after the CURL*
>> was added to the multi (in fact, on cancelation, just before the removal
>> from multi handle)
>
> I don't get it. What would the option do and why wouldn't that always be
> the desired action if the handle is removed in the midst of operations?
you are right.

as long as I can clearly establish from the FTP request the current state
and tell "am I at the end?" (if not, this is a cancellation, if yes, this is
a simple removal after operation).
can I test conn.proto.ftp->state for that (FTP_STOP)?

Armel
Received on 2006-12-04