[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting libpthread working again
From: |
Thomas Schwinge |
Subject: |
Re: Getting libpthread working again |
Date: |
Tue, 28 Jul 2009 00:42:51 +0200 |
User-agent: |
Mutt/1.5.11 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Getting libpthread working again,
Thomas Schwinge <=