curl-library
Re: HP-UX Saga
Date: Wed, 27 Nov 2002 10:49:03 +0100 (MET)
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?palm0002enReceived on 2002-11-27