Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!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: <8704230311.AA00968@uvabick.UUCP> Date: Wed, 22-Apr-87 22:10:59 EST Article-I.D.: uvabick.8704230311.AA00968 Posted: Wed Apr 22 22:10:59 1987 Date-Received: Sat, 25-Apr-87 19:48:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 62 Path: uvabick!mcvax!seismo!rutgers!ames!amdahl!ptsfa!vixie!paul From: paul@vixie.UUCP (Paul Vixie Esq) Newsgroups: comp.lang.lisp,comp.org.decus,mod.computers.vax,comp.sources.wanted Subject: Re: Need faster VMS spawn Message-ID: <601@vixie.UUCP> Date: 21 Apr 87 18:52:33 GMT References: <602@rdin.UUCP> Reply-To: paul@vixie.UUCP (Paul Vixie Esq) Organization: Vixie Enterprises, San Francisco Lines: 51 In article <602@rdin.UUCP> perl@rdin.UUCP (Robert Perlberg) writes: >[...] 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. [...] > 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. [...] At last, my VMS experience is good for something. First: Eunice, the UNIX(tm) emulator for VMS, uses this technique. Second: as far as I know, you don't need MACRO -- C will do. In VMS, the process creation is a little bit :-) different from fork/exec. They have LIB$SPAWN, which is a higher-level interface to SYS$CREPRC, which creates a 'subprocess' running the image (binary) of your choice. It has no relation to your original process other than in CPU and other accounting, and in that the original process has some special privs in killing or changing the priority of the subprocess. You will have to look at the System Services manual to find out what it's called, but I know that there is also a "exec"-like routine that overlays all or part of your address space with a new program image. The DCL command interpreter uses this -- that's why RUN with no arguments is so quick -- the system only has to load the new code into the existing address space, there's comparitively little system table munging for that. Anyway, here's what I remember about Eunice (from the manual, I've not seen the code). When you want to create a subprocess, check to see if any of the previously-created process is in hang-around state. If not, use SYS$CREPRC. When a subprocess finishes, (i.e., write your own exit() to catch them on their way out), have them open a mailbox (name it after the PID so the parent process can open the same one later on). Have them sit there in a SYS$QIOW waiting for something to arrive in that mailbox. When something arrives, treat the arrival as the name of the program to "exec" (like I said, see System Services manual for name, there's only one like it). If it sits there for more than, say, five minutes, make it exit -- the parent could be gone, or out of the section of code that was creating lots of subprocesses. Back in the parent, who as you've deduced by now must keep a list of what sub- processes have been created and what state they are in. In the parent, when you want to create a subprocess and you know there's one hanging around reading from a mailbox -- well, of course! You just open the mailbox and stuff the image name into it. Is there now vomit aplenty all over your keyboard? Sorry, that's how it's done. VMS has some good points, and this isn't one of them. Good luck... -- Paul A. Vixie {ptsfa, crash, winfree}!vixie!paul 329 Noe Street dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU San Francisco CA 94116 paul@vixie.UUCP (415) 864-7013