Daniel Stenberg wrote
> Jacob Kristhammar wrote:
> > To me it looks like multi_socket_action gets a
CURLM_CALL_MULTI_PERFORM
> > return value which it can't handle. (pycurl will raise an error
if the
> > return value is anything but CURLM_OK)
> >
> > The libcurl docs contain the following phrase:
> > "In modern libcurls, CURLM_CALL_MULTI_PERFORM or
CURLM_CALL_MULTI_SOKCET
> > should not be returned and no application needs to care about
them."
> >
> > What does modern refer to, is 7.18.2 considered modern?
>
> That's a rather sloppy phrase that we should improve. I think in
this case
> "modern" actually mean 7.19.0 or later, based only on when that
text was added
> in the manual but I haven't actually researched the source code for
this.
>
> > If so, what else might cause multi_socket_action to return
> > CURLM_CALL_MULTI_PERFORM)?
>
> The only thing that may cause it to get returned is that libcurl
returns it
> because it wants to do something more before waiting for the next
socket
> "event" so you need to call it again. The problem is of course that
this kind
> of API doesn't work very good with multi_socket_action() and that
is why we've
> worked on removing it in more recent versions.
> We have after all done eight releases since 7.18.2, boasting more
than 200 bug
> fixes...

I see. I will upgrade to a newer version and see if this solves the
problem.
I'll also add some precocious try/except to handle the the error and
treat it like CURLM_CALL_MULTI_PERFORM if the return value is -1.

Thanks!

-- Jacob
_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-python
Received on 2009-11-23