Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!eric
From: eric@pyramid.pyramid.com (Eric Bergan)
Newsgroups: comp.databases
Subject: Re: Client/server model in popular portable relational databases
Message-ID: <90677@pyramid.pyramid.com>
Date: 10 Nov 89 16:17:17 GMT
References: <24456@sequent.UUCP> <1989Nov10.061329.16565@odi.com>
Reply-To: eric@pyramid.pyramid.com (Eric Bergan)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 35

In article <1989Nov10.061329.16565@odi.com> dlw@odi.com writes:
>In article <24456@sequent.UUCP> sweiger@sequent.UUCP (Mark Sweiger) writes:
>
>		Now, if individual backend server threads could actually run
>   on different CPUs of the multiprocessor *concurrently*, there would be no
>   need for multiple server processes.  Since there is no easy way to achieve
>   this functionality in a portable fashion,...
>
>Second, let's return to reality; of course portability is an issue.
>The state of the world might be one of two things:
>
>(1) Every serious multiprocessor Unix vendor provides some way to run
>truly concurrent threads within a single Unix process; however, the
>details of how this work differ from one vendor to another.
>
>(2) There are serious multiprocessor Unix vendors who do not provide
>any way to run truly concurrent threads within a single Unix process.

	Actually, there are a number of standards efforts underway to
try and define a standard UNIX thread API. POSIX, UI, and OSF all
have groups meeting on this, and they actually are trying to converge
on a single standard. Further, since there are several reasonable models
to look at, its reasonable to assume that we can probably define a
useful standard. Note that defining the API does not necessarily restrict
whether the implementation causes the threads to be controlled in user
or kernel space, but in theory, as long as the API is complete, a developer
should not specifically care how the functionality is implemented. In 
particular, the IEEE POSIX Real Time group had a reasonable draft of a
definition of threads, called "p-threads", I believe. I do not know the
current status of the proposal, however.

-- 

					eric
					...!pyramid!eric