On 8/11/07, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
>
> > There are two major user scenarios here:
> > a) restart transfer using a handle with the same URL, etc as for the
> > previous transfer;
> > b) re-use the handle for another URL (could be after http - ftp), or
> other
> > params;
>
> Yeps, but case A above is probably not very common...

It is common, when a testing/loading application is simulating a client side
load
(e.g. curl-loader, just a few to mention :-) ).

> We could add a curl_multi_restart_handle().
> The only objection could possibly be that today an app is basically
> expected
> to detatch the easy handle, set new options and re-add it. It means that
> the
> easy handle is not attached to the multi when it gets options set.

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.

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.

Canceling a transfer in the middle could be another sophistication and a
separate
issue, like curl_multi_stop_handle() ...

-- 
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.