From owner-freebsd-hackers  Thu Nov 14 15:11:35 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA16498
          for hackers-outgoing; Thu, 14 Nov 1996 15:11:35 -0800 (PST)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA16486
          for <hackers@FreeBSD.org>; Thu, 14 Nov 1996 15:11:29 -0800 (PST)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA26489; Thu, 14 Nov 1996 17:08:25 -0600
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199611142308.RAA26489@brasil.moneng.mei.com>
Subject: Re: Programming technique for non-forking servers?
To: terry@lambert.org (Terry Lambert)
Date: Thu, 14 Nov 1996 17:08:24 -0600 (CST)
Cc: jgreco@brasil.moneng.mei.com, proff@suburbia.net, hackers@FreeBSD.org
In-Reply-To: <199611142228.PAA24870@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 96 03:28:02 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Was wondering when Terry would jump in..

> Threading in general has advantages over not threading.
> 
> *Kernel* threading has advantages in terms of SMP scalability.
> 
> Whether or not to consider *threading at all* is something that should
> be done independent of considering *kernel threading in particular*.

Threading in general has the distinct advantage of being moderately
portable: i.e. you can expect it not to work right somewhere.  :-)

> > Kernel level support for threading (or threads in general, for that matter)
> > may not be particularly portable in any case.
> 
> It will be irrelevant, being hidden below a POSIX API, no matter how
> it is implemented by the underlying system.

"Oh."

Well, what "will" be is irrelevant, because right now, what "is" does not
necessarily fit my notion of irrelevancy.

I agree that this should be the goal.  I disagree that what you are
saying exists today - because it does not.

> The POSIX threading uses signals to initiate context switches using a
> user space threads scheduler.

Hmmmm.

> > I guess I would not consider this viable unless someone told me up front
> > that there was a single platform that was being targeted, and there was
> > a clear advantage to the use of threads in the given context, and the
> > thread support on the platform in question was known to be good.
> 
> The clear advantage is context sharing between multiple threads of
> execution (which could be processes or threads or whatever) *without*
> resorting to UNIX IPC, which is (to say the least) arcane.  As a side
> benefit, context switch overhead is reduces between threads in the same
> thread group (the definition of a process), assuming that you don't
> implement your threads like SVR4 and Solaris implemented their kernel
> threads.

Assume I am familiar with the Solaris threads model.  The reason that
POSIX threads have reduced cxsw overhead is that signals are used?  (I
honestly do not know).

In any case, I usually try to be pessimistic when I write code.  That
probably means that I will not be writing threaded code for several
more years, at least if I plan to use the program under more than one
OS.  That is simply pessimism on my part about "POSIX threads".  ;-)

... JG