On Mon, Sep 7, 2009 at 1:43 AM, Daniel Stenberg<daniel_at_haxx.se> wrote:
> Right, but it should also set a timeout so that after a given time it should
> call your timer callback, you call libcurl and it should put the socket back
> in the game again. If not, it bugs.

And I think it shouldn't remove the socket in first place, but set a
zero event mask. Adding/removing sockets may be more costly on the
event loop than just disabling events.

> How is that a fix? How does libcurl then tell the app that it shouldn't care
> about traffic on that particular socket for now since it is "too fast" ?

Ah, yes. Obviously it's not. As effect it just hogs the CPU...

> Can you see why the timeout doesn't trigger, or if it does trigger why it
> doesn't put the socket back in the game correctly?

The initial timeout is too large and I don't see anywhere new timeout
set. Sketch of the execution of this last call to ..._socket_action:

- curl_multi_socket_action
    - multi_socket
        - multi_runsingle
            = changes state to TOOFAST
        - singlesocket
            - multi_getsock
                = state is TOOFAST, it doesn't return any sockets
            = sees socket as removed
                = calls user callback with REMOVE
                - sh_delentry(multi->sockhash, s) [multi.c:1804]
                = remove the socket from the easy handle? [multi.c:1810]
...

> Can you provide us with a small app that repeats this problem?

Attached examples/hiperfifo.c with some speed limit.