Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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: <7211@sybase.sybase.com>
Date: 27 Nov 89 17:04:31 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> <128@tacitus.tfic.bc.ca>
Sender: news@sybase.sybase.com
Reply-To: forrest@sybase.com
Organization: Sybase, Inc.
Lines: 93

(I'm not sure how far to continue this thread of discussion. I'll
be glad to stop, by popular demand, at any time.)

In article <128@tacitus.tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:

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

Trust me. The overhead of doing this won't be significant.

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

Again, I think that you're assuming that our kernel is more complicated
than it really is. There's no doubt that providing asynchronous cancelling
of a process is difficult because a process can be in any state when
the cancel occurs. Yet, there must be a way to change to a known
state in a graceful and predictable way. I'm not sure I understand
your concerns but again, I think that what we've done is the best
that could be done, given the usual constraints of portability and
speed.

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

I think you misunderstand the architecture of our kernel. It's not
one that allows arbitrary code to be run, like a Unix or VMS kernel.
All the "processes" that can be run are actually part of the server
executable image (with the exception of Remote Procedure Calls).
A process that runs under our kernel must behave according to various
rules imposed by the kernel. These include rules for giving up the
processor, how to start new processes, etc. By the way, we don't do
timeslicing. Our processes run either to completion or until they
voluntarily give up the CPU. 

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

First of all, since we don't do time slicing in our kernel I don't
see any issue here. Second of all, even if we did do time slicing,
since this would be handled by our kernel, and paging would be handled
by the O.S. kernel I again don't see what the issue is. Our kernel
would not be (and is not) aware of paging taking place. Third of all,
having a bunch of small O.S. processes would bring up all those nasty
problems relating to locking and syncronization that caused us to
use the single process model in the first place.

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

I'm happy to profess complete ignorance of CICS. I'll probably live
longer as a result.

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

Me too. Since we starting to repeat ourselves why don't we just call
it quits.

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


Brought to you by Super Global Mega Corp .com