Re: cthreads->pthreads

[Samuel Thibault]

Hey,

It'd be good if you could avoid mixing issues :)

Barry deFreese, le Mon 15 Sep 2008 13:50:10 -0400, a écrit :
> In many cases the mutex stuff gets overriden from chtreads-compat in 
> libpthread.  However, in the startup code _hurd_preinit_hook() seems to 
> call init() from hurdsock.c instead of init_first.c.

Err, really?  How could it? (it's a static function!)  You should
disassemble the caller to check the actual address being called.

> What is especially strange to me (that I haven't figured out yet)
> is that I get different code paths on the cthreads ext2fs.static
> than I do on the pthreads one. My pthreads calls doinit1.11759 after
> _startup(), while the cthread one seems to call init1().

What _startup?

> Am I chasing a non-issue here.  Should there be no cthreads calls at
> all (in other words, are glibc modifications going to be required)?
> Or is it a non-issue since it is within glibc?

libpthread should already be libthreads compatible, no need to modify
glibc, except bugs.

> Below is a backtrace of the failure.  The locales thing is an issue but 
> I'm focusing on the strange assert at the moment.
> 
> Thoughts?
> #0  0x080c8088 in __current_locale_name (category=5) at localename.c:25
> #1  0x0808b726 in __dcigettext (domainname=0x811a9ee "libc",
> #2  0x0808aa0a in __dcgettext (domainname=0x811a9ee "libc",
> #3  0x0808a7c4 in __assert_fail (assertion=0x811575c "__pthread_threads",
> #4  0x08070352 in __pthread_mutex_unlock (mutex=0x8165d00)
> #5  0x080819ce in _hurd_thread_sigstate (thread=89)
> #6  0x080aba2b in __sbrk (increment=2104) at ../hurd/hurd/signal.h:185
> #7  0x0808a2e5 in __libc_setup_tls (tcbsize=12, tcbalign=5) at 
> #8  0x0808a52f in __pthread_initialize_minimal () at libc-tls.c:248
> #9  0x08089c69 in doinit1.11759 ()

Just see what's happening: while initializing libpthread, we lock/unlock
a thread, which calls pthread_self etc. while libpthread is not
initialized yet. No wonder an assertion fails.

Samuel