On Thu, 6 Mar 2008, Ingo Krabbe wrote:

>> This code doesn't "plan" to reuse file descriptors at all, it just reports
>> the actual situation at that moment.
>
> its not the reuse of file descriptors but the reuse of contextual data I
> otherwise need to encapsulate or duplicate.

I didn't understand that. What contextual data? libcurl reports what file
descriptors it currently uses and for what purpose.

> Of course I will try to see, where this behaviour is implemented. Also I
> will try to add some event loop interfaces to make this easier.
>
> The thing about the REMOVE call is: You don't need it while you process a
> request. The filedescriptor actually doesn't matters. I don't need it, but
> I forward it to the event loop library.

Well, perhaps you don't need it but I know others certainly do. If libcurl
doesn't use the file descriptor anymore, why should it not call REMOVE on it?

> When the REMOVE call is triggered now I'm not sure if there will be other
> calls on the filedescriptors (OUT-REMOVE-IN-REMOVE-?-)

Of course not, file descriptors are created and killed during operations.
That's what they do.

> What I really need is contextual data, that I attached to the callbacks and
> I need a signal when to create it, when to change behaviour (in/out) and
> when to close and destroy the contextual data, since that is completely
> controlled by the asynchronous request:

But these file descriptors are the actual file descriptors libcurl uses.
They're not explictily bound to a particual request. And a single request can
(and will) cause multiple descriptors get created, used and killed.

> What the libcURL library lacks is the signalization of the finished request.

How so? It decreases the counter of running handles and then you know a handle
is completed and then you read the curl_multi_info_read() to figure out which
handle it was.

> The simulation of the final request state can be done but is quite complex.
> When you take into account that you know the final request state is reached
> at the moment you close the socket.

No it's not. You don't know when the final socket is closed.

> You see that closing time is an essential moment of time of the programs
> that use libcURL.

No I don't actually...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html