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

Hello Daniel,

Thursday, April 19, 2001, 8:51:36 PM, you wrote:

>> THREAD_SAFE but despite, it works. Now trouble starts if one adds a
>> mycurl[1].Start() (after the second setUrl) which results in an
immediate
>> segfault and core dump that is obviously related to libcurl since
it
>> won't occur if check isn't called in Run() (run is some sort of
main()
>> for the thread).
> I can't say I understand your piece of code, as some parts are
obviously
> missing.

It "runs" the way I posted it if the libraries are installed on the
system (i.e. Common C++ and libcurl are installed).

> Also, you didn't mention what version of the library this is, so I
> assume it is 7.7.1.

Right, built again from the FreeBSD port with
LDFLAGS="-pthread -D_THREAD_SAFE", CPPFLAGS="-pthread -D_THREAD_SAFE"
set.

> Are you doing curl_easy_init() for each new thread? You can't re-use
the same
> handle over thread-boundaries.

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.

> If you do, where exactly is the crash occuring?

When the second thread's curl_easy_perform() is called.

> Can you show us a stack trace?

Sure. gdb bt yields the following:

[regular output]
Fatal error '_waitq_remove: Not in queue' at line ? in file
/usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = ?)
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGABRT, Aborted.
0x282b58dc in kill () from /usr/lib/libc_r.so.4
(gdb) bt
#0 0x282b58dc in kill () from /usr/lib/libc_r.so.4
#1 0x282ffdbe in abort () from /usr/lib/libc_r.so.4
#2 0x282cc789 in _thread_exit () from /usr/lib/libc_r.so.4
#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 ?? ()

> Another note, a source code comment says: "docs say one has to set
the
> options again after each request". It isn't true. If you want the
options to
> remain the same, you don't have to touch them again.

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).

>> Now is there any halfway reliable information about the thread
safety of
>> libcurl (Daniel states thinks it should be, but that he didn't
test)?
> I didn't, but others have. I think it is fairly safe to say that
libcurl is
> thread-safe.

Hmm. I tryed to recompile libcurl with -pthread -D_THREAD_SAFE but it
didn't help.

>> despite the use of
>>
>> cout << curl_easy_setopt(curl, CURLOPT_MUTE, 1);
>> curl_easy_perform() will dump everything to the console
> *everything* ? If you include the file itself in "everything" it is
because

The contents of the file to receive, I'm dumping the header to stdout,
that is clear (so I see the malformed requests) but I'd prefer if the
lib wouldn't dump the rest.

> by default all output of received data is passed to stdout. If you
mean the
> progress meter stuff, that is shut off separately.
> I know this should probably be fixed and documented better.

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.

>> [2] I wonder whether I should try to write some Python wrapper to
the lib
>> to see if performance would improve.
> I would welcome a Python wrapper, so if you end up making one, I'm
all ears!
> ;-)

Never done any Python wrappers before but...

Best regards,
 Gabriel

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

iQEVAwUBOuAXUsZa2WpymlDxAQGWEQf+LxebOHLiphtBDqYmPohBiWTlPsUyKmtR
28vo7s4HfZPT5vypH/cxiqAhUmnHkjwIzAFRWfVjNa132p243/82bdYQ716US6JG
J02DH2eMTO0GPfIl/x/V4kwRMi1CajWCAND7dvs07h92CcBFmxJhL1Paq8rr4yEK
XSa6HKMfiaxuV0TqbSrBJBTguDEIo0dK+sUQd94/MOXXFExGekYR8Qymclfvz7e3
LD1HFgCcFAx4KzsqUr1Hy3rDBTTKKPhf/AcMHfrUKGfazgvOrJQiObvYYXeMrzMU
RofJ71xAjvnlSRUTUgBfIQjQDkiC4qzrVLhy7bpdExzX2uwzafyl5w==
=ySVs
-----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-20