Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!binky!tim
From: tim@binky.sybase.com (Tim Wood)
Newsgroups: comp.databases
Subject: Re: Client/Server model in popular portable relational databases
Keywords: Client,Server
Message-ID: <7045@sybase.sybase.com>
Date: 13 Nov 89 18:48:51 GMT
References: <24285@sequent.UUCP> <1205@unify.UUCP> <123@tacitus.tfic.bc.ca>
Sender: news@sybase.sybase.com
Reply-To: tim@binky.UUCP (Tim Wood)
Organization: Sybase, Inc.
Lines: 33

In article <123@tacitus.tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:
>In article <1205@unify.UUCP> nico@unify.UUCP (Nico Nierenberg) writes:
>...
>>my question is why can a user process do a better job of multi-tasking
>>then the OS can.  Please consider this a devil's advocate position, and
>>I am really curious what you all think.
>
>Yeah, me too!...
>
>And where do things like Mach or Sun's multithreaded routine support fit in?

In Sybase's case, that feature of Mach and SunOS did not exist when we
archtitected our system.  Even if it did, we might very well not have 
used it because: a) it is not available on all platforms we would want
to run on; b) there's no guarantee that their lightweight process scheduling 
would be optimal for our RDBMS, whereas we fully control that by writing
our own; and c) our system behaves more uniformly on different platforms
because in all cases, the same policies for scheduling DBMS tasks are
in effect.  All we ask is to occupy as much memory and CPU time as possible! :-)

The aim of our design is to have a small amount of memory and non-DBMS CPU
time per user by using that memory and CPU only for our own 
overhead instead of getting the OS into the act for each DBMS
task.

>
>Chris Hermansen                         Timberline Forest Inventory Consultants

-TW
Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608	  415-596-3500
tim@sybase.com          {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
		This message is solely my personal opinion.
		It is not a representation of Sybase, Inc.  OK.