Jeff Roberson wrote:
Does the tid allocator quickly recycle numbers?
Yes, I saw this behavior.
This would be different
from the pid allocator if it does. Basically every syscall that takes a
numeric id would be subject to this problem.
I expect application programers will more often specify binding from
within the running thread using -1.
Don't know, but I feel it is more often the calling will be made
for threads within same process, so searching it globally is not
efficient in this case, and garbage id may hit an irrelevant thread in
another process.
However, there is a seperate problem that is endemic with our current
threading support. thread_find() requires the proc lock and returns a
pointer to the found thread. However, the proc lock is not sufficient
to ensure that the thread is not exiting and recycled after
thread_find() returns. I believe virtually every user of this interface
may be subject to races.
threads are linked into or removed from process with proc lock held,
why will a linked-in thread be recycled ?
And while were on the subject. Why is it lwpid_t anyway? We don't have
lwps, we have threads.
lwpid_t is used for thread id, I thought marcel introduced this type, by
the way, gdb also understands lwpid_t, I have not found any problem with
it, it is just an integer.
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
