From owner-freebsd-arch  Wed Oct  9 10:41:57 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4BF9A37B401; Wed,  9 Oct 2002 10:41:56 -0700 (PDT)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id B4E7C43E65; Wed,  9 Oct 2002 10:41:55 -0700 (PDT)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 95088AE2B7; Wed,  9 Oct 2002 10:41:55 -0700 (PDT)
Date: Wed, 9 Oct 2002 10:41:55 -0700
From: Alfred Perlstein <bright@mu.org>
To: John Baldwin <jhb@FreeBSD.org>
Cc: Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG,
	Igor Sysoev <is@rambler-co.ru>
Subject: Re: Scheduler framework.
Message-ID: <20021009174155.GJ95327@elvis.mu.org>
References: <Pine.BSF.4.21.0210091001270.37238-100000@InterJet.elischer.org> <XFMail.20021009132958.jhb@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <XFMail.20021009132958.jhb@FreeBSD.org>
User-Agent: Mutt/1.4i
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

* John Baldwin <jhb@FreeBSD.org> [021009 10:30] wrote:
> 
> On 09-Oct-2002 Julian Elischer wrote:
> > 
> > 
> > On Wed, 9 Oct 2002, Igor Sysoev wrote:
> > 
> >> On Wed, 9 Oct 2002, Julian Elischer wrote:
> >> 
> >> > If a thread mailbox IS provided:
> >> > the syscall is entered.
> >> > the thread blocks. A second thread is invoked and attached
> >> > to the KSE, which is disconnected from the original thread.
> >> 
> >> Sorry, where did this second thread come from ?
> > 
> > there is a thread_allocator that allocates threads on demand.
> > 
> > Actually the process ahs a couple of spare threads "Up its sleave"
> > so it doesn't have to go to teh thread allocator every time..
> 
> Which kind of defeats the point of letting the slab allocator manage
> memory from a larger whole-view perspective. :-P

Kind of, but not entirely, since one can guarantee exclusive access to
a private pool and therefor doesn't need locks.  I'd be nice if
there was a macro or something to do this in a official sanctioned
API.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message