Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!iuvax!bsu-cs!corwin
From: corwin@bsu-cs.UUCP
Newsgroups: comp.unix.questions
Subject: Re: dsb unix vs. dec's vms
Message-ID: <689@bsu-cs.UUCP>
Date: Fri, 22-May-87 02:27:51 EDT
Article-I.D.: bsu-cs.689
Posted: Fri May 22 02:27:51 1987
Date-Received: Sat, 23-May-87 10:38:34 EDT
References: <5828@shemp.UCLA.EDU> <34ab0e42.8be4@apollo.uucp> <667@bsu-cs.UUCP>
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 46
Summary: CLI not OS responsible

In article <667@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
> In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the 
> Greatest [or so he claims]) says this about VAX/VMS:
> >                           ...Also, I hate the shell (or command inter-
> >pretor) in VMS.  Why can't anybody in DEC write something like C-Shell?
> >I think VMS is absolutely able to support a C-Shell-like command interface.
> 
> VMS is not able to support a C-Shell-like command interface for a rather
> important reason.  The UNIX shell interface depends heavily on process
> creation and many commands create several processes.
> 
> VAX/VMS is extremely inefficient at creating new processes.  When the
> VMS command interpreter executes a user program, it does not create a
> new process, but simply does the equivalent of a UNIX exec() system
> call.  Thus the current invocation of the command interpreter
> effectively dies and is replaced by the user program.  (How it regains
> control after the user program terminates is a long, long story that
> I don't fully understand.)
> 

I'm into hazy territory here (anyone from Digital feel free to jump
my case if I go astray...), but I believe the problem lies not with
VMS but with the DCL interpreter. When DCL spawns, it usually hauls
it's "environment" (used loosely here; not like Unix) along with it.
This means that the new process has to get a copy of the global symbol
table, the logical name table, etc. There seems (to me) to be no
reason for a process creation slowdown in the OS. The $CREPRC system
service is in main memory; so are the data structures it manipulates.
Unless the process is swapped out immediately after creation, a new
process sould run with little delay. It's the way DCL passes it's
environment that slows things down. That and the loading of a new
program image from disk, but then that's an I/O problem more than
an OS difficulty.

I do know Digital markets DEC/Shell, which is supposed to be like
Bourne shell. I don't know the speeds on it, but it is supposed to
spawn processes.

As far as the image exit handler return path, yeah, that's messy.
If my technical info is way off base, let me know.


-- 
Paul "Corwin" Frommeyer        "Experience is no substitute for competence."
UUCP: 
	{seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwin