Oh good, I was just about to submit the same problem.

Most of the time curl_multi_perform returns almost immediately (0ms), but
every so often it blocks for half a second or more. I also assume that
this behavior is accidental and will be fixed.

Mike

At 11:08 AM 3/17/2004, you wrote:
>Bugs item #917642, was opened at 2004-03-16 14:08
>Message generated for change (Tracker Item Submitted) made by Item Submitter
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=100976&aid=917642&group_id=976
>
>Category: https
>Group: bad behaviour
>Status: Open
>Resolution: None
>Priority: 5
>Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Daniel Stenberg (bagder)
>Summary: SSL connect blocks curl_multi_perform
>
>Initial Comment:
>curl 7.11.0 (i686-pc-linux-gnu) libcurl/7.11.0
>OpenSSL/0.9.6b zlib/1.1.4
>Protocols: ftp gopher telnet dict ldap http file https
>ftps
>Features: SSL libz NTLM
>----------------------------------------------------------
>I am using HTTPS post requests to create a secure
>connection to a server. The client (libcurl) side uses
>the multi interface calling curl_multi_perform every
>10ms or so from a timer dispatched by the UI package
>(fltk) which blocks the UI during the processing of the
>timer. I have been assuming that curl_multi_perform is
>essentially a non-blocking interface and therefore is
>ok to call in this way (which it is nearly all of the
>time). However, if the server (apache) shuts down
>while the client is establishing a connection,
>libcurl's curl_multi_perform can get stuck in a select
>call waiting for openssl to connect. If I attach gdb
>when in this state I get the following backtrace:
>----------------------------------------------------------
>#0 0x420d3b2e in select () from /lib/i686/libc.so.6
>#1 0x40244f08 in __JCR_LIST__ () from
>/usr/lib/libcurl.so.2
>#2 0x402285cf in Curl_http_connect (conn=0x0) at
>http.c:971
>#3 0x4022edab in Curl_protocol_connect
>(conn=0x88206e0, hostaddr=0x0)
> at url.c:1908
>#4 0x4023cb92 in curl_multi_perform
>(multi_handle=0x8723ab8,
> running_handles=0xbffff464) at multi.c:413
>----------------------------------------------------------
>Is this a bug or is my assumption about the
>non-blocking nature of curl_multi_perform simply wrong?
>
>Thanks,
>
>Stuart Lovett
>stupublic_at_yahoo.com
>
>
>----------------------------------------------------------------------
>
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=100976&aid=917642&group_id=976
Received on 2004-03-16