[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Two items concerning libpthread
From: |
Thomas DiModica |
Subject: |
Two items concerning libpthread |
Date: |
Mon, 30 Jul 2012 16:17:20 -0700 (PDT) |
Monsieur Thibault,
As you seem to be the person committing things to libpthreads, the Makefile
reads at line 246:
ifeq ($(IN_GLIBC),no)
$(inst_libdir) = $(libdir)
endif
Make keeps dieing on line 247 there: it complains about an empty variable.
I am trying to build libpthreads as a part of the hurd, not as part of libc.
The fix seems to be to change the line to read:
inst_libdir = $(libdir)
Mr. Walfield,
Repeating a conversation you had with Herr Schwinge:
<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
So, what exactly is wanted here? Should have_kernel_resources be split into two
predicates: have_wakeup_port and have_kernel_thread? Would it suffice to show
that in the implementation both resources are treated atomically?
Just curious. Thomas has been too busy to comment (or I insulted him).
Thomas D
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Two items concerning libpthread,
Thomas DiModica <=