Date: Mon, 3 Mar 2008 16:41:46 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Xu <davidxu@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Jeff Roberson <jeff@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/kern init_main.c kern_cpuset.c kern_thread.c syscalls.master src/sys/sys _types.h cpuset.h proc.h types.h src/lib/libc/sys Symbol.map Message-ID: <20080303163838.H920@desktop> In-Reply-To: <47CCACCB.7010900@freebsd.org> References: <200803020739.m227dNLe039427@repoman.freebsd.org> <47CBBE21.4060104@freebsd.org> <20080303022505.P920@desktop> <47CCACCB.7010900@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080303163838.H920>