On Fri, 8 Aug 2008, Albert Lee wrote:

>> No, when it fires you don't set another timeout by yourself, but you should
>> pretty soon get a new timeout callback for the next timer.
>
> This was a source of confusion that I was referring to in the docs.

But how is this confusing in the docs? Or rather, what wording should be added
or changed to make it more clear?

> Thanks for clarifying. The problem I have been observing the is definitely
> related to the timeout callback invocation - perhaps there is an incorrect
> optimisation carried over from multi_timeout?

I don't see how, as multi_timeout is just getting the closest timer and
returns that time. But sure, I'm not excluding the possibility of a bug!

I'm just in need of a source code for an app that shows the problem happening,
as I've done plenty of coding with the socket API and I've not experienced
this problem myself.

-- 
  / daniel.haxx.se