On Tue, 4 Mar 2008, David Xu wrote:
Jeff Roberson wrote:
Does the tid allocator quickly recycle numbers?
Yes, I saw this behavior.
I see, it uses unr. We should introduce some flags to this to prevent
quick recycling anyway.
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.
This is an application race. I think if we slow down the id recycling
we should not bother with it.
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 ?
You are right. I thought it was only the PROC_SLOCK. But as long as the
PROC_LOCK is held that's ok.
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]"
