Re: curl_multi_perform usage & easy handle "reset"
Date: Mon, 13 Aug 2007 10:01:10 +0200 (CEST)
On Sun, 12 Aug 2007, Robert Iakobashvili wrote:
>> If we add curl_multi_restart_handle() it pretty much relies on the fact
>> that after a particular easy handle has completed a transfer, you change
>> options of it while it still is connected to the multi handle, and then you
>> restart it. I'm not saying we can't do that, just that it makes the usage
>> someone different.
> Yes, this is a different usage mode to be described and documented in due
We could possibly also make curl_easy_setopt() refuse to work if the app is
setting options to it while it is "in progress". I haven't really made up my
mind if it would be good or bad...
>> Also, we need to consider how to react if an app calls
>> curl_multi_restart_handle() in the middle of a transfer.
> Good point. The first hypostases of the function may return an error, when a
> handle is in the middle of a transfer.
Yea, or it could act exactly like a remove/add handle would do, which is to
abort and reset the transfer from the start. A separate argument to the
curl_multi_restart_handle() function could be considered to select which the
behaviors that is desired.
> Canceling a transfer in the middle could be another sophistication and a
> separate issue, like curl_multi_stop_handle() ...
Yeah. This made me think on instead providing a single function like:
That can get get told to control the easy handle (while) added to a multi
handle in various ways:
- RESTART, unconditionally restart this easy handle's transfer from the start,
re-init the state
- RESTART_COMPLETED, restart this easy handle's transfer but only if the
existing transfer has already completed and it is in a "finished state".
- STOP, just stop this transfer and consider it completed
These are still just ideas and brainstorming...
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-08-13