Daniel Stenberg wrote:
> On Mon, 29 Jun 2009, Mohun Biswas wrote:
>> - Is there a technique for "serializing" the multi API? By which I
>> mean something like a flag to change the "as little as possible"
>> philosophy to "as much as possible", which would make it behave much
>> more synchronously like the easy API.
>
> I don't understand what such a "serializing" would mean so I can't
> really tell how hard it would be.

I'm thinking of a flag (or environment variable?) which would cause
curl_multi_perform to change its behavior: instead of doing whatever
magic it now does to service all handles without blocking, it simply
loops through each handle it currently owns and calls curl_easy_perform
on it. This would of course throw away the whole value of the multi API
and make it a roundabout way of using the easy API, but it would be a
useful debugging device IMHO. Of course the same basic thing could be
done at the app level instead but that would require substantial new
coding, and the point of the flag would be to simplify the behavior
without significant reworking of the algorithm. Changing the code in
order to debug it gets into Heisenberg territory.

On a similar topic, is there a way to loop through the handles currently
in the multi stack? Again, of source, the app could use its own logic to
keep track of which easy handles are in use, but the multi handle has to
know that anyway so it seems easier and more robust to include it in the
API. I see curl_multi_info_read but that's a little different because it
reports on transfers, not handles. In other words I believe that if I
make a bunch of easy handles and add them to the multi handle but don't
call curl_multi_perform, there's no way to ask the multi handle which
easy handles it has. If nothing else, this could be used to call
curl_easy_cleanup on each handle when done.

Am I missing it? Would a patch be accepted?

MB
Received on 2009-06-30