Path: utzoo!utgpu!watmath!att!rutgers!ucsd!swrinde!gem.mps.ohio-state.edu!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: <125@tacitus.tfic.bc.ca>
Date: 17 Nov 89 03:39:44 GMT
References: <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca> <7037@sybase.sybase.com>
Reply-To: clh@tacitus.UUCP (Chris Hermansen)
Organization: Timberline Forest Inventory Consultants, Vancouver BC
Lines: 51

In article <7037@sybase.sybase.com> forrest@sybase.com writes:
>...
>I retort :
>  Although in my original posting I never said that Sybase is better at
>  implementing the elements of a multitasking kernel than a native O.S., I'll
>  accept your challenge and give you a couple of examples of how
>  certain features of our multitasking kernel are better than one
>  O.S., VMS.

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 reply :
>  Dense might not be the right word. In any case, I don't know if
>  our competition requires special privileges. This wasn't the point
>  I was trying to make. Any program of any kind that doesn't requires
>  special privileges shouldn't be able to crash the machine on which
>  it is running unless the machine is very badly tuned or else the
>  O.S. isn't intended for production environments. I know that I feel
>  good knowing that in the only case I know of that a machine running
>  Sybase has crashed it has been because of a bug in VMS.

Fair enough.  I guess the point I was trying to make is that your competition
probably doesn't require these privileges either.  I can certainly appreciate
why a software vendor feels more comfortable being able to tell customers
that no system crashes are due to bugs in the vendor's software.

As I recall, the original post was basically asking for information as to
why Sybase appeared to be so much more efficient, in terms of its use of
system resources.  Your response sounded to me like "because we have
implemented our own, more efficient, routines for accomplishing the same
tasks".  I would not dispute that your company has good reasons for
approaching the problem this way; however, I feel it is reasonable to
wonder exactly how much measurable benefit there is to your theoretically
better approach.

I am not trying to dump on you (or Sybase) at all, sir.  In particular, I
support any company that tries to implement better software through design.

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