This is the mail archive of the
mailing list for the glibc project.
[Q] bug-iconv3 and locking functions.
- From: Carlos O'Donell <carlos at baldric dot uwo dot ca>
- To: libc-alpha <libc-alpha at sources dot redhat dot com>
- Date: Thu, 21 Aug 2003 11:34:46 -0400
- Subject: [Q] bug-iconv3 and locking functions.
The comment in libc/iconvdata/bug-iconv3.c notes:
/* And load some more. This call hang for some configuration since
the internal locking necessary wasn't adequately written to
handle a dynamically loaded libpthread after the first call to
The iconv_open function, through a chain of other function calls relies
on __libc_lock_* to do all locking. What is the purpose of the above
testcase? From what I can see, without threading the __libc_lock_*
functions do nothing, with threading they are pthread_mutex_t
structures. On the first call to iconv_open we setup a number of global
variables without locking. We then load the linuxthreads library, which
will do it's own initialization. Lastly iconv_open is called again to
test if it hangs. On hppa it does. Is this indicating that our mutex
functions are _not_ behaving as expected?
A clarification of the testcase purpose would help me out. Is there
perhaps a document anywhere indicating the purpose and reasons for each