Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!think!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!phobos!forrest
From: forrest@phobos.sybase.com (Jon Forrest)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <7139@sybase.sybase.com>
Date: 20 Nov 89 05:39:02 GMT
References: <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca> <7037@sybase.sybase.com> <125@tacitus.tfic.bc.ca>
Sender: news@sybase.sybase.com
Reply-To: forrest@sybase.com
Organization: Sybase, Inc.
Lines: 29

In article <125@tacitus.tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:
>From our (rather limited) experience with VMS, I don't blame you for
>implementing your own multitasking here; it probably was easier than sorting
>out all the SYS$HOOEY that you would have needed to make things work under
>VMS.
>
>Also, all the yack about overhead (in other responses to Jon's original
>posting) of process creation brought out at least one interesting question:
>by the time the DBMS vendor's thread handling stuff is jazzed up to
>include accounting, etc, etc, might the differences between the standard
>O/S process creation and the DBMS stuff not be all that great?
>

I don't know what you are expecting to see in a multi-threaded
environment but I think that you would find that a process in our
kernel is much simplier than you might think. In fact, it's my
personal belief (that I have no facts to backup) that process
creation time in our kernel is negligable. It's certainlly less
than on BSD Unix. But again I don't hold this against BSD Unix.
Our kernel is a special purpose kernel that can leave a lot of
the hard stuff to the operating system kernel.

----
Anything you read here is my opinion and in no way represents Sybase, Inc.

Jon Forrest WB6EDM
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422