Path: utzoo!attcan!uunet!samsung!usc!ucsd!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: <7167@sybase.sybase.com>
Date: 21 Nov 89 16:43:16 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> <127@tacitus.tfic.bc.ca>
Sender: news@sybase.sybase.com
Reply-To: forrest@phobos.UUCP (Jon Forrest)
Organization: Sybase, Inc.
Lines: 61

In article <127@tacitus.tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:
>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?
>

Funny you should ask this question because this is very similar to
something I'm looking at now. My current approach doesn't require
opening an accounting file. Instead, we can just put the accounting
data in a row in a table. After all, we're talking about a relational
database. Then, an accounting program need only perfrom the relevent
queries to get the accounting data from the table to the system accounting
file. (This is not official. We may do something entirely different or
not do anything at all.)

>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?
>

Sybase and, as far as I know, all our competition provide some way
of iterrupting a command while it is executing. This is not a problem.

>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 :-)
>

I don't know enough about the internals of other operating systems
to give a full description of how we differ from each system.
So, instead I'll tell you what we do when we create a process. It's
really quite simple. We find a free process data structure, fill
in a few fields having to do with scheduling, assign a stack to
the process, and add the process to a queue. All this takes less
than 20 lines of code. If you look at the VMS Internals and Data
Structures manual you can get some idea of how complex process
creation can get.

----
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