From owner-freebsd-arch Sun Jan 6 1:39:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 34E5D37B402 for ; Sun, 6 Jan 2002 01:39:22 -0800 (PST) Received: from dialup-209.247.139.117.dial1.sanjose1.level3.net ([209.247.139.117] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16N9lv-0006VS-00; Sun, 06 Jan 2002 01:39:19 -0800 Message-ID: <3C381AF7.C8D8FDFA@mindspring.com> Date: Sun, 06 Jan 2002 01:37:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alfred Perlstein , arch@freebsd.org Subject: Re: freeing thread structures. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Remember that threads are short lived in the kernel. They exist only > as long as a user thread 'dips' into the kernel, and are reaped when the > control passes back into userland. This is because a single userland may > spawn a virtually unlimmitted number of syscalls as they are now > asynchronous. Now, if they all use the same credential, > (which is shared between processes that have not moved to change them, > (with a lazily evaluated copy-on-write semantic)) then if one syscall > changes the cred at exactly the instant that another > uses it, the second thread can reference an inconsitant cred, leaving > room in the future for some sort of hack. I the scheme we have now, > each thread, as it is assigned to a process, takes a reference to > the processes ucred as it starts. That ucred will never change. > when it is reaped teh reference is dropped again. If in the mean while > another thread has applied to change the processes creds, then > it will allocate a NEW ucred with a reference of 1, unreference the > old one and substitute in the new one. All threads continue to work with > the ucred that was in effect when they started their dip into the kernel. > When they complete they return control to teh userland scheduler and > do a thread_exit() which will decrement the ucred reference. If the > process changed ucreds in the mean while it is concievable that the > reference count may go to 0 and it be freed. Uh, then just increment the reference count twice in threaded processes, so that there's no chance of inconsistancy: you invoke the copy-on-write semantic trying to change it, thereafter. Your problem only exists on write, in any case, and as you say, they are read-only, so there's no inconsistancy possible, I think. Even if it were an issue (e.g. you allowed them to be writeable with a reference count of exactly 1, as well as on create), you don't have a problem if you are careful about order of use and duplication (fill it out completely before assignment of the problem pointer). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message