On Tue, 26 Nov 2002, Moffet, Scott wrote:

(This seems more like a libcurl issue, why I CC this reply over to the
libcurl list as well. I think we should take future mails in this subject
there.)

> I've compiled libcURL for HP-UX 11.00 using OpenSSL 0.9.6g with the HP aCC
> compiler. I'm having an odd problem I was hoping someone could help me
> with.

I've never used aCC nor have I any access to any HP-UX machines, but I'll
give my view of things anyway.

> Client requests are received in XML and parsed into separate fields. The
> XML fields are then used to populate an HTML form and it is posted as an
> HTTPS POST to a web server through libcURL. libcURL receives the response
> page, which I then parse for the response data and build an XML response
> string.
>
> MULTIPLE TRANSACTION MAY OCCUR FROM MULTIPLE THREADS!

But each thread is using its own unique curl handle, right?

> The problem I'm having is that, 50-80% of the transactions work fine. The
> other 20-50% fail. libcURL receives a portion of the page (it varies from
> 50% to 100%) and quits. If I haven't received the entire page, I miss the
> digital signature. If I edit the libcURL code and change it to use
> blocking sockets, 100% of the transactions work, but acts as if it is
> single threaded.

You don't need to edit source code for that, just run configure with
--disable-nonblocking.

But I don't follow you here. What makes you say it "acts as if it is single
threaded" ? I fail to see how the (non-)blockingness of the sockets interfere
with how the threads are working.

> I added some debugging messages to the libcURL code and found that when
> non-blocking sockets are used, OpenSSL will sometimes return
> SSL_ERROR_SYSCALL with errno set to EAGAIN. The problem is that errno is a
> global variable and one thread may change it before another thread looks at
> it. At least, that is how it appears.

Is it really (a problem with errno and threads)? Most modern unixes have
fixed the early problems with errno being a single global variable.

I wonder if we can possibly tread the condition

  ((err == SSL_ERROR_SYSCALL) && (errno == EAGAIN))

Similar as the SSL_ERROR_WANT_WRITE case, and just let libcurl try again.

Could you add a check like that and test if it makes the behavior different?

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en