Hello! On Tue, Jun 23, 2009 at 12:05:42AM +0200, I wrote: > On Sun, Apr 12, 2009 at 05:32:12PM +0200, I wrote: > > When linking the pthread tests against a libpthread built (with Samuel's > > TLS patches) from CVS HEAD (or any of the Viengoos branches, for that > > matter) I always get this: > > > > $ ./test-1 > > test-1: ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103: > > __pthread_setup: Unexpected error: (ipc/send) invalid destination > > port. > > Aborted > > $ ./test-1-static > > test-1-static: > > ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103: > > __pthread_setup: Unexpected error: (ipc/send) invalid destination > > port. > > Aborted > > > > I tracked this down to the 2008-08-16 __pthread_free_threads change -- > > apparently nobody ever tried to use the CVS HEAD libpthread since then? > > (We absolutely need to come up with better automated testing methods...) > > The pthread library was now trying to reuse kernel threads that have been > > invalidated before. I created the attached patch to get that fixed again > > (plus the malloc to calloc patch needed for CVS HEAD). Neal, is this > > approach correct? I have stolen the thread_suspend thing from Viengoos > > -- is that correct for Mach as well? (And the while (1) loop is > > superfluous for all variants, isn't it?) At least, this way all of the > > libpthread test suite programs complete to satisfaction, both dynamically > > and statically linked. > > I now put my preliminary (unfinished) patch into the > master-fix_have_kernel_resources branch. The commit currently also has > some additional comments by Neal in the commit message (for the next > person to work on it).
For convenience, here a Neal's comments again:
<neal> do you want a reply on the libpthread one inline?
<neal> the short answer is: yes, that's a bug
<neal> unfortunately, your fix is not enough
<neal> the predicate controls two resources: the wakeup port and the
thread itself
<tschwinge> Oh, right, I see.
<neal> also, there may be a race:
<neal> set the predicate to free, then kill the thread
<neal> that's not so good
<neal> so a proper solution requires a bit more thought
<tschwinge> I think I wondered about that as well. But isn't there the
same problem with Viengoos?
<neal> it is difficult as cleanly committing suicide is hard :-)
<neal> could be
<neal> on viengoos, I don't actually deallocate the thread in
pt-thread-halt.c
<neal> I just call suspend
<neal> the thread is only deallocated in pt-thread-dealloc.c
I had a look at this issue again, but didn't get to a state where I'd say
that I really understand how thread->have_kernel_resources is to be
handled correctly. Neal, can you help?
Is it in the first place correct to call __thread_terminate in
__pthread_thread_halt, or should this be __thread_suspend (followed by
__thread_abort?)? (And where should the kernel thread then be destroyed
eventually?) In the Viengoos case you call __pthread_thread_halt from
__pthread_thread_dealloc, for Mach this is not done, and only the wakeup
port is being destroyed in there. And so on; I'm confused. What are
these allocation and deallocation functions exactly meant to do these
days?
Regards,
Thomas
signature.asc
Description: Digital signature
