cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Fwd: Re: Close callback

From: Ingo Krabbe <ikrabbe.ask_at_web.de>
Date: Thu, 6 Mar 2008 21:14:23 +0100

Am Donnerstag, 6. März 2008 20:23:14 schrieb Daniel Stenberg:
> On Thu, 6 Mar 2008, Ingo Krabbe wrote:
> > You never should call CURL_POLL_REMOVE when you plan to do more IN or OUT
> > calls on one fd I think. It would be better to reuse the context:
>
> 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.

>
> > that would really be better if you can provide it.
>
> If you can see any bugs or obvious flaws in the code, please let us know.
> Or if you improve the code, send us a patch!

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.

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

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:

start request <-- create data
..... work upon it
close request --> close the data and do final processing

As you can see here the actual work is done on the close signal. Thats the
point where the data is ready or has reached another final state.

With multi asynchronous interfaces there are several layers of final states.
Here for example:

        a request is done
        a complete multi communication has finished

The latter can be controlled by handles falling to 0 which is a nice signal
you get while executing perform functions.

What the libcURL library lacks is the signalization of the finished request.
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.

Not only the request has then reached a final state but also the context I
attached to the request.

You see that closing time is an essential moment of time of the programs that
use libcURL.
Received on 2008-03-06