Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!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: <128@tacitus.tfic.bc.ca>
Date: 23 Nov 89 02:11:34 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> <7167@sybase.sybase.com>
Reply-To: clh@tacitus.UUCP (Chris Hermansen)
Organization: Timberline Forest Inventory Consultants, Vancouver BC
Lines: 71

In article <7167@sybase.sybase.com> forrest@phobos.UUCP (Jon Forrest) writes:
>In article <127@tacitus.tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:
...
>>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?
...
>...                         Instead, we can just put the accounting
>data in a row in a table. After all, we're talking about a relational

OK, but that's not quite what I was asking; whether you put it in an
accounting file or a table, some process somewhere has to collect the info,
open the thing (or at least lock it), emit the info, and close (or at least
unlock it) - IE THERE'S A MORE-OR-LESS EQUIVALENT AMOUNT OF OVERHEAD IN EACH
CASE.

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

OK again; but what I was trying to get at is, using your approach or the
vanilla O/S process approach, a bunch of info related to the process has
to be kept, in order to, among other things, monitor and cancel it - IE
THERE'S A MORE-OR-LESS EQUIVALENT AMOUNT OF OVERHEAD IN EACH CASE HERE, TOO.

>>....        I'm just curious about how much unnecessary activity in normal
>>process creation you can eliminate in your server kernel.  It seems to me
...
>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.

OK yet again; but this is just setting a process up to be executed.  If
you're comparing it to the standard UN*X fork/exec, you haven't begun
the exec yet; I don't even see that you've completed the equivalent of a
fork, as you haven't made a data space for your process.  So, what about
the control program that actually executes the process?  Presumably, it's
doing some kind of time-slicing in order to ensure response time; it must
also be doing the data-space allocation, collection of accounting info,
opening/closing/locking/unlocking tables, etc. etc.  This doesn't seem to
be a whole lot less than what a regular O/S does for a living, especially
when shared memory is available for interprocess communication, and when
forks (these days) don't commonly involve quite as much overhead as they
did back in the old days.

What about the extra overhead incurred by your (non-kernel) time slicer
operating beneath the UN*X time slicer?  Are you sure that you don't pay
some kind of performance penalty by having one large user process operating,
rather than a bunch of small ones, when paging is an issue?

I can understand that you might want to do all this yourself in some systems;
for instance, Software AG has certainly followed this approach in dealing
with IBM mainframe OLTP applications.  Even bad old CICS looks like this.
I would also suppose that an MS-DOS (network?) version would require the
roll-your-own approach.  And, as I said before, it's probably easier to
do it yourself under VMS than figure out how to get VMS to do it for you.
All that being the case, it makes sense that your approach is more self
reliant.  This is a different issue than the one we have been discussing,
though (ie, performance).

I'm getting a little nervous about the amount of net we're using here; should
we be carrying on this discussion over e-mail, instead?

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