Re: Getting libpthread working again

[Thomas Schwinge]

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