On Wed, 6 Dec 2006, Armel Asselin wrote:

> 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()...!

> the ABOR question is secondary

Why so? I thought it would be cool to address it at the same time.

> 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?

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