Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!uvabick.UUCP!uucp
From: uucp@uvabick.UUCP.UUCP
Newsgroups: comp.os.vms
Subject: Submission for mod-computers-vax
Message-ID: <8704220627.AA24667@uvabick.UUCP>
Date: Wed, 22-Apr-87 01:27:04 EST
Article-I.D.: uvabick.8704220627.AA24667
Posted: Wed Apr 22 01:27:04 1987
Date-Received: Fri, 24-Apr-87 02:39:11 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 30

Path: uvabick!mcvax!seismo!ut-sally!husc6!linus!philabs!rdin!perl
From: perl@rdin.UUCP (Robert Perlberg)
Newsgroups: comp.lang.lisp,comp.org.decus,mod.computers.vax,comp.sources.wanted
Subject: Need faster VMS spawn
Message-ID: <602@rdin.UUCP>
Date: 16 Apr 87 20:40:07 GMT
Organization: Resource Dynamics Inc., New York
Lines: 20
Posted: Thu Apr 16 16:40:07 1987

I saw an article a while back in net.lang.lisp (that's what it was
called at the time) in which someone mentioned that they had written a
lisp interpreter for VMS which ran subprograms by spawning just one
child process and letting it hang around and using it to run all
subprograms since spawning a process takes so long in VMS.  We are now
in the situation of desperatly needing to increase the speed with which
our system can start subprocesses.  We are running MicroVMS V4.3 on a
MicroVAX II.  If anyone can tell me how to use the abovementioned
technique or any way to start subprograms faster than with lib$spawn()
we would greatly appreciate it.  If we can't find any better way we are
going to be forced to link all of our object code (currently about 13
Megabytes of object code constituting 66 separate executables) into one
gigantic executable (gag!).

Thank you.

Robert Perlberg
Resource Dynamics Inc.
New York
{philabs|delftcc}!rdin!perl