Hi,

On Die 22.08.2006 23:50, Daniel Stenberg wrote:
>On Tue, 22 Aug 2006, Alexander Lazic wrote:
>
>>the current output show us that the socks callback was called *after*:
>>
>>CURLM_STATE_DO, /* start send off the request (part 1) */
>>
>>how about to call the callback *before* the CURLM_STATE_DO?!
>
>I don't understand neither your conclusion nor your question:
>
> 1 - CURLM_STATE_DO is a state in the multi handle state machine
>
> 2 - multi_runsingle() is internally called to deal with everything
> multi-interface and _after_ that function returns, the checks are
> made for the socket states etc and the socket_callback is called
> for the sockets that have changed state.

I think the my fault was that i have seen it from fd point not from
application point.

You are right the application make a run and *after* this first run
then it would be called the socket callback, is this statment right?!

>It is not possible to call the callback until the change is made, so it
>MUST be after multi_runsingle(). But why bother? This should not be a
>problem. If it is, that's a bug.

Hm, ok.

Then it is possible that a transfer is done *before* the callback is
called, right?!

>>You can get both outputs (ok,nok) with some printstatments in libcurl from:
>
>BTW, I'm not sure its relevant but a microsecond is one million during one
>second, while your app sets the tv_usec to something larger than so.

Thanks for hint.

>>http://none.at/ok.run.txt
>>http://none.at/nok.run.txt
>
>They are quite hard to read and draw any conclusions from.

Sorry, but it was a quick shot, could be to quick ;-)

I have now printed it out and looked site by site ;-)

--- ok
.
.
==> socket_callback() socket 11 easy 0x805a898 what IN
==> socket_callback() Add info for socket 11 READ
<<<setsock() event_add() for fd 11 with action 1

start multi_runsingle()
  multi_runsingle() easy->state :8:
writecallback() 05: 512, total 512
end multi_runsingle()

start multi_runsingle()
  multi_runsingle() easy->state :8:
end multi_runsingle()
.
.

---
--- nok
.
.
.
==> socket_callback() socket 11 easy 0x805a898 what IN
==> socket_callback() Add info for socket 11 READ
<<<setsock() event_add() for fd 11 with action 1
start multi_runsingle()
  multi_runsingle() easy->state :8:
writecallback() 05: 512, total 512
end multi_runsingle()
start multi_runsingle()
  multi_runsingle() easy->state :8:
writecallback() 04: 512, total 1024
end multi_runsingle()
.
.
.
---
>Isn't the problem that eventcallback and timercallback are the only
>functions that count down number of alive connections, update the
>timeout etc, so if none of them are called then those actions won't be
>performed.
That's the point ;-)
What I have seen is if the request/response pair is fast enough or small
enough the callback isn't call, as I have seen.
>If none of those callbacks are ever called, it would mean that all
>transfers should be completed by the time event_dispatch(); is called
>in your program? ... And really, it should probably make sure that
>running_handles is non-zero before getting called.
The main difference in both run is that after the last call of set
setsock in ok.run.txt the writecallback is only once called where in the
nok.run.txt the writecallback is called for every fd/easy handler and
then the callback.
The whole libcurl run is done before the main program call the
update_timeout(), that's strange?!
When I use a 256k it works always as assumed and designed ;-)
What do you think, is it a 
[ ] program
[ ] lib
[ ] design
problem?!
I hope the question/statement is a little bit cleaner ;-)
Regards
Alex