This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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
     iconv_open.  */

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]