From owner-cvs-src@FreeBSD.ORG Tue Mar 4 02:39:35 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F104106566B; Tue, 4 Mar 2008 02:39:35 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id D3CF58FC16; Tue, 4 Mar 2008 02:39:34 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m242dQ7U038550; Mon, 3 Mar 2008 21:39:30 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Mon, 3 Mar 2008 16:41:46 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: David Xu In-Reply-To: <47CCACCB.7010900@freebsd.org> Message-ID: <20080303163838.H920@desktop> References: <200803020739.m227dNLe039427@repoman.freebsd.org> <47CBBE21.4060104@freebsd.org> <20080303022505.P920@desktop> <47CCACCB.7010900@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, Jeff Roberson , 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 02:39:35 -0000 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. > > >