Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Nov 2000 16:23:00 -0500 (EST)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG, smp@FreeBSD.ORG
Subject:   Re: Threads (KSE etc) comments
Message-ID:  <Pine.SUN.3.91.1001121160717.7102A-100000@pcnet1.pcnet.com>
In-Reply-To: <200011211824.LAA27595@usr08.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Nov 2000, Terry Lambert wrote:
> > yes, but that gives the ability to use M times as much CPU as a
> > nonthreaded process.
> 
> If you won't give it to me, I'll just take it, instead, either
> by using rfork() and a shared memory segment for my global data,
> which gets me the equivalenet of a threaded environment, for all
> practical purposes, or I'll just fork() and run multiple instances
> of myself.  Either way, you don't get to tell me not to compete
> as multiple processes, and I can throw a KSEG based policy out the
> window, without needing your permission to do it.  Worse, there
> is additional context switch overhead introduced by this (the
> same reason Linux kernel threads are a bad idea), and everyone
> gets to pay the penalty for my application.

I have to agree with Terry.  You can't dictate what application
writers will do.  If they want more CPU and they can't get it
with the threading model we provide, then they will get it
another way.  Limiting PTHREAD_SCOPE_PROCESS threads to 1 KSEG
with only 1 quantum doesn't stop someone from [r]fork()'ing
to get more CPU.

Let's admit that this is what some applications will want to
do and allow them to do it within our threading model.  No,
we won't do it by default, but we can provide simple hooks to
allow an application to request more "CPU reservations"
(a KSEG under the current definition).

Note that I am only talking about scope process threads.
Scope system threads are bound to their own KSEG/KSE pair.

-- 
Dan Eischen


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.SUN.3.91.1001121160717.7102A-100000>