Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!van-bc!tacitus!clh
From: clh@tacitus.tfic.bc.ca (Chris Hermansen)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <127@tacitus.tfic.bc.ca>
Date: 20 Nov 89 16:42:21 GMT
References: <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca> <7037@sybase.sybase.com> <125@tacitus.tfic.bc.ca> <7139@sybase.sybase.com>
Reply-To: clh@tacitus.UUCP (Chris Hermansen)
Organization: Timberline Forest Inventory Consultants, Vancouver BC
Lines: 42

In article <7139@sybase.sybase.com> forrest@sybase.com writes:
...
>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.

OK; let's suppose that I'm managing a computing center, and a bunch of
users want to get a database server.  In order to pay for the server, I
decide to implement per-user accounting on the server.  Now let's assume
that I buy Sybase's product :-)

Is it not the case that, in order to satisfy my desire for accounting, 
you are going to have to open an accounting file, write a record, and
close the file for each process created?  And will this not require locks
or process synchronization or some such thing?

Furthermore, let's suppose that user Joe Bloggs screws up a select statement
and puts a != into the join condition unstead of an =, causing the server
to go off and start retrieving zillions of lines of stuff from the database.
What mechanism do you provide to stop his processes in the back end?  Does
this not imply some kind of `process registration' in your kernel?

Now, I certainly wouldn't claim to be a systems hacker, so I could be way
off base on the above.  I don't dispute the utility of lightweight processes
in general; I'm just curious about how much unnecessary activity in normal
process creation you can eliminate in your server kernel.  It seems to me
that the *only* thing you don't require is a separate address space for each
process (since the processes presumably don't do the kind of things normal
user programs are prone to do in ordinary operating systems, like trample
all over memory they don't own).

Can you give us some specifics as to what significant issues you feel you
can safely ignore?  Without revealing proprietary secrets, of course :-)

Regards,
Chris Hermansen                         Timberline Forest Inventory Consultants
Voice: 1 604 733 0731                   302 - 958 West 8th Avenue
FAX:   1 604 733 0634                   Vancouver B.C. CANADA
uunet!ubc-cs!van-bc!tacitus!clh         V5Z 1E5