cURL / Mailing Lists / curl-library / Single Mail


Re: curl_multi_perform usage & easy handle "reset"

From: Daniel Stenberg <>
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
> course.

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:
Received on 2007-08-13