On Thu, 26 Sep 2002, Fabrizio Ammollo wrote:

> I have one question about the subject because the examples covering the
> multi interface do not perform something similiar to what I need to do.

Right, we need more examples and better docs here.

> Basically, I have to do a select() to wait for events from a TCP listen
> channel, and also from the sockets already connected with the clients. Upon
> certain events from one or more clients, I need to get an URL using
> libcurl, and at the end of each transfer I have to send the received data
> to the corresponding client.
> I thought about using the multi interface because it allows to make
> multiple transfers without using multithreading, and I am able to select()
> on the multi handle fd's to call curl_multi_perform only when new data is
> available.

Sounds like a school-book example for which we introduced the multi
interface.

> There's one thing which is not entirely clear to me: after calling
> curl_multi_add_handle, the library returns with an explicit code that tells
> me to call curl_multi_perform

It doesn't require you to immediately call curl_multi_perform(). The return
code merely tells you that there is (at least might) still be more data to
transfer and thus you're kindly requested to call curl_multi_perform() again
before you select() again.

> but simply looping as in the examples until it returns something different
> from CURLM_CALL_MULTI_PERFORM could block, not in the real sense of
> blocking, because I have read that libcurl is non blocking

That's at the whole idea of the multi interface, yes. (It still blocks a bit
too much at times though, but we're slowly improving.)

> but of transferring (in the worst case) data from each of the easy handles
> already associated to that multi handle and not only to the one just added,
> and so probably taking more time than necessary ?

That's a question of definition. How can it take "more time than necessary"?
If there's data to transfer all the time, then how can that be more than
necessary?

But certainly, if you feel that taking care of other business you might have
is more important that transferring the URLs you've added to the multi
handle, then fine, do that before you call curl_multi_perform() again.

> I see that using a temporary multi handle is impossible, because removing
> the easy handle from it and then adding it to the "main" multi handle which
> manages the already "connecting" connections would destroy the state
> information about the easy handle (because its state it set to
> CURLM_STATE_INIT).

Yes, you add an easy handle to a multi handle to get the transfer done,
removing it again means that you cancel the transfer and re-adding it means
you re-do the transfer from the start.

I don't understand how you would use this "temporary multi handle" to achive
what you want. You mean simply moving an easy handle from the multi handle
you're transferring files on to one that you don't call curl_multi_perform()
on?

> Is there a way to avoid this problem without having a (new) way to tell a
> multi handle to perform the transfer only on a certain easy handle, or a
> set of easy handles ?

So you add N number of easy handles but only want L of them to transfer data?
May I ask you why?

But no, we don't have any current way to only transfer data on a selected set
of easy handles within a single multi handle. I haven't yet come up with a
scenario in which one would want that.

If this is really needed/wanted, we must consider a way to add this
capability.

> Another thing is, when curl_multi_perform returns the number of still
> running connections and I see that it has dropped by 1 (or more), is there
> a simple way of determining which easy handle(s) finished execution, or do
> I have to call curl_multi_info_read continuously and look for all the
> CURLMsg about finished easy handles ?

When the number of still running connections change, you can get the
completed easy handles (as there may be more than one that are completed in
the same function call) by calling curl_multi_info_read(). If the amount
doesn't change, there's no point in calling it.

I'm interested in your opinions and ideas on what we can do to make libcurl
fit your needs. The multi interface is still growing up.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf