> Ok. I'll do that state check fix (somewhat differently) and commit.
Got it, thanks!

> > handles that show COMPLETED in multistate, but
> > aren't getting picked up as CURLMSG_DONE

> I believe you can fix this bug in hiperfifo.c like this:
> ...
> + break;
> ...

Ah, I see now - should this be clarified in the multi_info_read docs?
Maybe something like:

" After receiving a msg value of CURLMSG_DONE, subsequent calls
to curl_multi_info_read may exhibit undefined behavior, at least
until the completed easy handle is removed. "

> at least it seems to fix it for me.
Yep, works for me too.

> > the app just seems to stall, and the CURLOPT_* timeout settings don't
> > have any effect. Whenever it gets in this state, libevent's event loop
> > eats up 100% CPU.

> When this happens, does it stall forever or just "a while" ?

Well, I'm not sure about "forever", but safe to say it's a really long time.
At least a couple hours, and my progress callback doesn't get updated, either.
It usually only stalls out after several minutes, and it's not something
that is easy to reproduce consistently, so trying to "tweak out" the problem
can be a time-consuming task.

One thing I noticed, in my update_timeout() function (which I copied from
your hiper/hiperv.c) is that the function doesn't check the value returned
in timeout_ms before passing it on to evtimer_add(), which can result in
the timeval's tv_usec getting set to a negative value (-1000).

I'm not sure how to deal with this, possibly either:

if ( timeout_ms <= 0 ) { return; }
 -- or --
if ( timeout_ms <= 0 ) { timeout_ms =0; }

I tried both ways, and it looks like if I return immediately,
without setting the timer, then I still get the stalling, but
not the CPU hogging.

The other way (setting tv_usec to zero) seems to be no different
than setting to -1000 (it still stalls and eats up CPU).

I didn't find anything in the docs about exactly when the call
to curl_multi_timeout() is needed, the comment in "hipev.c" says
"after every call to libcurl" which sounds a bit extreme.

This seems like a burden on the application programmer that
might possibly be better handled internally, maybe using
something like a CURLMOPT_TIMEOUT_FUNCTION that could be
defined in the application, and invoked by the library
whenever it sees fit. ( Just a thought. )

For what it's worth, I found that libevent can be replaced
fairly easily with glib-2.x in the demo. Although have haven't
found much difference in the performance, it does hint that
curl-hiper might integrate nicely into GTK applications.

I can post the code if you like ( keeping in mind that glib is LGPL ).

Sorry for the long ramblings, I'll shut up now :-)

 - Jeff
Received on 2006-10-08