From owner-freebsd-hackers Thu Nov 14 17:20:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA29914 for hackers-outgoing; Thu, 14 Nov 1996 17:20:41 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA29905 for ; Thu, 14 Nov 1996 17:20:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA25059; Thu, 14 Nov 1996 18:07:48 -0700 From: Terry Lambert Message-Id: <199611150107.SAA25059@phaeton.artisoft.com> Subject: Re: Programming technique for non-forking servers? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 14 Nov 1996 18:07:48 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, proff@suburbia.net, hackers@FreeBSD.org In-Reply-To: <199611142308.RAA26489@brasil.moneng.mei.com> from "Joe Greco" at Nov 14, 96 05:08:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > 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. Heh. Since we don't have kernel threading, the pthreads API, which is a POSIX threading API, "hides" the implementation. You don't have to worry about it being incompatible with kernel threading API's, since there aren't any. 8-). > > 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). Nope. The Solaris/SVR4 kernel threads have higher context switch overhead because the block a kernel context in a blocking system call instead of converting the blocking system call into a non-blocking call and woing a thread context switch. Basically, even though they are called "threads", you will be changing which kernel schedulable entity is running each time you make a blocking call. A user space implementation (like pthreads) exports a blocking call interface to the thread making the call, but converts it into a non-blocking call and a threads context switch inside the same kernel schedulable entity. In other words, the Solaris/SVR4 implementation will give away process quantum which "rightfully" belongs to you when you make a blocking system call, but the pthreads implementation will only give away quantum when all threads are blocked (no more work to do) or when your process has consumed its *entire* quantum and is forcibly context switched. > 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". ;-) You might as well have been pessimistic about "POSIX open" several years ago, when it was possible for technically "conforming" implementations to have different behaviour. 8-). If the system has threads, it's a good bet that if you use the POSIX threads interface, no matter what local "extensions" they have for binding user space threads to kernel threads, etc., the interface you will be using will be constant across systems. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.