Date: Sat, 5 Jan 2002 11:17:57 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@freebsd.org Subject: Re: freeing thread structures. Message-ID: <Pine.BSF.4.21.0201051100540.34014-100000@InterJet.elischer.org> In-Reply-To: <20020104210829.T82406@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Jan 2002, Alfred Perlstein wrote: > * Julian Elischer <julian@elischer.org> [020104 20:57] wrote: > > > > In mi_switch AFTER the switch to the new thread has been completed, > > (which is one possibility) the sched lock is held, so freeing any resource > > that wants to own a normal sleeping mutex would seem to be an instant > > panic. ANother possibility is to simply queue it for later freeing by > > another entity, but I REALLY would rather avoid having a reaper thread (or > > init) do it. > > Please just use a reaper thread for now, it will not stop you from > optimizing it later. Haven't we gone over this? 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.. Possibly the answer is to have an async free-er PLUS the allocator can call the free-er if it looks like it's pool is empty. Maybe, on the other hand, just the allocator and a few other critical points may be enough on their own.. Say, the allocator, the entry point for the userland thread_exit(), and maybe some other place that will happen even if we are not doing those two things.. Probably in the upcall code.. 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) > > -Alfred > 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.0201051100540.34014-100000>