bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]