Date: Sun, 06 Jan 2002 01:37:59 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Alfred Perlstein <bright@mu.org>, arch@freebsd.org Subject: Re: freeing thread structures. Message-ID: <3C381AF7.C8D8FDFA@mindspring.com> References: <Pine.BSF.4.21.0201052019440.35785-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C381AF7.C8D8FDFA>