>> OK so could we tell to Curl_done what is the current multi state?
>
> No, that info is multi.c private info and nothing else should bother about
> that state.
>
>> from what i understand this cancellation stuff could profit any protocol,
>
> Yeah, some more protocols could probably use some attention and make sure
> they behave correctly when the handle is removed in the midst of
> operations.
>
>> 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.
>
> Yes, if that is exactly what you want to know then I agree it makes little
> sense and we should rather pass on that information. But like for this
> case, I don't think that is all you want to know...
>
> BTW, "prematurely" isn't really the right word for what you're asking for
> since the connection might be re-used over and over again and you're only
> interested to get the "cancelled" state set true during the periods in
> which the handle is in use - while a transfer is in progress.
>
> It just struck me. This above described state is active between Curl_do()
> was called until Curl_done() is called. We could easily add a boolean
> somewhere in the connectdata struct that holds that info and then it would
> be very easy for whatever function to check for "pre-Curl_done()"
> activity. In fact, we already have such a boolean: conn->bits.done is set
> FALSE in Curl_do() and set TRUE in Curl_done()...!
so I have to check if using this bit yields the right results, if yes i'll
be happy with that as well.

>> the ABOR question is secondary
>
> Why so? I thought it would be cool to address it at the same time.
it's more important to prevent hanging for one minute than winning 0.5
seconds with a well crafted ABOR handling.

>> 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
>
> Perfectly OK function-wise yes, but when we're working hard on removing
> unnecessary FTP commands to decrease number of round-trips etc, it would
> feel a bit counter-productive to add commands that aren't needed.
>
> Of course I might be nitpicking now.
>
>> 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.
>
> You're of course right that ABOR is not *required* until we try to re-use
> the connection, but IMHO it would be nicer to abort the previously setup
> file transfers properly so that the server can free resources etc when the
> client is obviously no longer interested in the transfer previously
> initiated. Or do you think it is a waste in case the connection isn't in
> fact re-used later on?
we could both use ABOR before resing the connection and run the ABOR command
just before trashing the connection 'to help' the server, but i'd definitely
would not be very happy to wait for the server to accept the ABOR command
after the cancel (which may happen during application shutdown).

Armel
Received on 2006-12-07