Date: Sat, 5 Jan 2002 20:30:20 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <bright@mu.org>, arch@freebsd.org Subject: Re: freeing thread structures. Message-ID: <Pine.BSF.4.21.0201052019440.35785-100000@InterJet.elischer.org> In-Reply-To: <3C376690.6B14328@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
You are "partially" confused. On Sat, 5 Jan 2002, Terry Lambert wrote: > Julian Elischer wrote: > > Yes but there must be a good synchronous way of doing this.. > > An async method will always lead to a lag in teh number of threads > > actually available, as it will.... hmmmm > > > > I was going to say that the availability of threads will be > > limited because there will e actually free threads that have not yet been > > properly freed, by which I mean that they have not had their ucred's > > crfree()'d yet etc. However it just occurs to me that > > maybe if we ran short of threads, we are probably in a situation to > > free them and make them available to ourselves.. > > Uh, if the problem is creds, under what circumstances in POSIX > is it permissable to have multiple threads in a process with > different credentials? we don't do this.. see later. > > In other words, aren't you asking the wrong question here? I > think the question is not "how can I free creds in thread_exit?", > it's "why am I storing creds per thread in the first place?". see later > > > The ready-to-free thread structureas don't have anything except for > > the ucred in them that really requires freeing before they are put into > > the thread cache. so it's not a lot of waste to let them gather up a > > bit... (They'd just be in the cache anyhow, unless it was full > > in which case the stackpages would be dissociated and freed) > > Yes, exactly. And referencing the cred via the thread doesn't > make sense anyway (IMO)... 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. The rule is that ucred is read-only. and thus requires no lock to access it from any thread that has it. it is the credential that was in effect when the syscall was started. There is NO syscall to change the ucred of a running thread. so Albert's idea is not a goer at this time :-) > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > 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?Pine.BSF.4.21.0201052019440.35785-100000>