-----BEGIN PGP SIGNED MESSAGE-----

Hello Daniel,
Friday, April 20, 2001, 4:18:43 PM, you wrote:

>> If I haven't completely misunderstood the concept of the threading
lib,
>> I'd say I do so as I do curl=curl_easy_init() in the constructor of
the
>> class (which works, BTW). IMHO this should yield a completely
independent
>> curl ptr (as the counters definitely are independent, i.e. they
don't
>> increment if not told to do so in the same thread). The other
member
>> variables of the class are also separate as a dump_config statement
will
>> yield the different configs if the program is told to use them.
> So, would you be capable of following (single-steppping) the second
thread
> into the curl_easy_perform() call?

I couldn't get that damn gdb to do anything useful so far (which is
one of my major points why I don't like C/C++, interpreted languages
are inherently much easier to debug). But I'll see...

> What if you create a few threads first _without_ calling
curl_easy_perform()
> and then call it on the second or third thread? If this is a libcurl
bug, it
> really should work then. If it doesn't, the problem is not in curl.

About the only solution to achieve this is using a flag that tells
the thread whether to actually execute curl_easy_perform() or not.

It doesn't work this way:
calling curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 1)0
calling curl_easy_setopt(curl, CURLOPT_URL, url);0
calling curl_easy_setopt(curl, CURLOPT_MUTE, 1)0
calling curl_easy_setopt(curl, CURLOPT_WRITEHEADER, stdout)0
calling curl_easy_cleanup(curl)
leaving check()
01
calling curl_easy_setopt(curl, CURLOPT_NOPROGRESS, 1)0
calling curl_easy_setopt(curl, CURLOPT_URL, url);0
calling curl_easy_setopt(curl, CURLOPT_MUTE, 1)0
calling curl_easy_setopt(curl, CURLOPT_WRITEHEADER, stdout)0
Bus error (core dumped)

Now to make things even worse: it sometimes will fetch the data the
first time called (appears to be somehow related to the url used,
http://localhost works this way, http://10.2.2.220 does not)
and then crash with a segfault. If I set only the first thread to do
the
check, it will work like before having only one thread.

I'm beginning to believe that I'd be better off with implementing a
dummy HTTP(S) library myself for this purpose, after all, I don't need
any sophisticated POST stuff etc. (Despite, I figured that this whole
threading stuff has a way bigger CPU overhead than having different
processes.

>> #3 0x282c61be in _waitq_remove () from /usr/lib/libc_r.so.4
>> #4 0x282c81fd in _thread_kern_scheduler () from
/usr/lib/libc_r.so.4
>> #5 0x0 in ?? ()
> Hm, can this be an abort() or signal problem? Although libcurl
should not
> mess with any signals unless you specify a timeout.

> Do you know what in libcurl that causes this? I mean, like what
function call
> or about which function in the lib?

I just know that the crash's always happen when I call
curl_easy_perform(). Following the warning on the page, I didn't dig
into the
lib to see what that actually does.

>> I've there got another oddity when the lib is called from C++: half
the
>> request (the even ones, IIRC) generated are completely broken as
the
>> apache_error_log shows the following: [Thu Apr 19 19:29:28 2001]
[error]
>> [client 10.2.2.70] Invalid URI in request GET ÿÿÿÿ HTTP/1.1 then
correct
>> and malformed requests are alternating (broken ones are always the
same).
> That might be because you pass a char pointer to libcurl that you
free or
> reuse before libcurl is done. You must make sure they remain present
until
> libcurl is done using them.

This problem has gone (I've got my doubts about the maturity of this
whole threading stuff).

> The main configure script already attempts to detect thread-safe
versions of
> all libc/resolve functions in use that need such.

Ah ok.

>> The strange thing is: from C, CURLOPT_MUTE works without any
problems. -
>> From C++, it is ignored. The progress meter stuff, OTOH, gets
deactivated
>> like it should.
> Somehow, I don't think libcurl behaves differently depending on your
language
> of choice, but I figure the use of the lib differs...

Sure. But C++ supports C as a subset (for the very most parts, some
really old stuff IIRC got stripped but the compiler would tell you if
you happen to use that. Despite, the linking against the precompiled
lib shouldn't make any difference...)

>> Never done any Python wrappers before but...
> Me neither, but that's one the remaining major languages that
unfortunately
> still lacks a libcurl interface.

It's a very nice language, actually (much better than Java, IMHO). If
it only
were faster.

Best regards,
 Gabriel

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2i

iQEVAwUBOuFXx8Za2WpymlDxAQFZIQf/ZygvlIDqo/OJSocJ6m9UMFE9mKnVfT9D
01cke3ZWupiEsikCrl8V9CoUb9aSNxSdAZza87zBFHFMzG/mC8A7J/y/kxJVpzL8
+o1UMlIjk8C2R6lcvMIq7kIdpe3TnSLh0MSFySXctIAp5bUWqhxP+q3A5jjH6+Kr
0f68zvwCajvHqKixQXVvfSvhXbmImB+04BOvY9X3Kxv22WyuT6ohAX/hk2hGsd9o
9Db7HOcxrx0z5fRZ7NoB+UyUPbuTrxrQ7pOSIQVoZfbwO8a3pAOSa3buiarGy/bC
f0Sft6TCd9V424aO+6S+itzeqftityD70YTJclqJP+g5f0pdjO/K1A==
=S/dc
-----END PGP SIGNATURE-----

_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-04-21