Am Samstag, 8. März 2008 20:23:22 schrieb Daniel Stenberg:
> On Sat, 8 Mar 2008, Ingo Krabbe wrote:
> > Yes you are right. I've done this now and finished the example just as I
> > want it to run (process on done requests), though the real work has to be
> > done during io callbacks since I need the current request that I work
> > upon:
>
> Can you clarify what you mean with this? If the "real work" need to be done
> in "io callbacks" (I assume you mean write callbacks), then why don't you
> do it in them? But the request is of course never completed within the io
> callbacks so I don't see how the completion of a request is related to what
> work you need to do when you get data.
>
> > handle_ofs = global->handles;
> > while ( CURLM_CALL_MULTI_PERFORM ==
> > (code = curl_multi_socket_action(global->curl,
> > fd, 0, &global->handles)) );
> > handle_ofs -= global->handles;
>
> This is not correct. curl_multi_socket_action() will write the number of
> currently active handles in that counter so your decrement is wrong here.

What is wrong with it I just look if the returned handles have changed during
the curl_multi_socket_action calls.

>
> > if ( handle_ofs != 0 ) {
> > /* here the check can be done */
>
> What check?

The check for completed easy handles.

>
> I find it slightly annoying that you've now posted many mails on this
> topic, and I still don't understand what your point is.

Hmm, I wouldn't have thought that this is so hard to understand. My code
isn't that long, though the package might be big, since it contains a PDF
file, that you can only compile, when you have TeX installed, so I included
it for convenience.

The actual code test-it.w of the example is about 450 lines of code, with all
comments and empty lines.

My point is the transfer of data between libcURL and the three event types as
they are used in the example:

1. What I call IO Events are the events from the even loop that will be
executed by the event loop (here qt).
2. The socket callbacks are the functions called by the multi_socket functions
of curl.
3. The write callbacks where the data can be read.

We have a logistic problem here: Data will be revieved in the write callbacks
(3) but the request state is only clear in the IO callbacks (1).

I try to solve this logistics problem between libcURL and program event loops,
since this problem is the central show stopper to use asynchronous IO.

Next I will try to unfold the multi_socket functions a bit, that I can see,
where to change the data logistics a bit.

In my example I tried to clarify the logistics by introducing the global_data,
socket_data and url_opdata structures.

The global_data is available anywhere. The socket_data is created and managed
during the socket_cb. The url_opdata is used in the WRITE callbacks.

What we need is url_opdata during the request complete detection (/* here the
check can be done */),

I don't know whats so hard to understand. It is a static fact. Everyone who
writes programs driven my asynchonous events needs to solve this data
logistic problem.
Received on 2008-03-08