Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!a.cs.uiuc.edu!uxc.cso.uiuc.edu!urbsdc!aglew From: aglew@urbsdc.Urbana.Gould.COM Newsgroups: comp.unix.wizards Subject: Re: Interactive Background Processes Message-ID: <57900015@urbsdc> Date: 14 Jul 88 14:08:00 GMT References: <16374@brl-adm.ARPA> Lines: 14 Nf-ID: #R:brl-adm.ARPA:16374:urbsdc:57900015:000:733 Nf-From: urbsdc.Urbana.Gould.COM!aglew Jul 14 09:08:00 1988 >Date: Fri, 1 Jul 88 15:59:05 EDT >From: Ken Van Camp> > When running large, computationally-intensive programs (such as >finite element codes, ray tracers, and other simulations), it is usually >desirable to run the program in the background so the user is free to >perform other tasks, logout, etc. Unfortunately, under Unix, selecting >background processing precludes interactivity in the software. I code my backgrounded programs (in my case, performance monitors that have to run *much* longer than one login session) in two parts: the actual background part, that does its work and listens to a socket, and an interactive part, created on demand, that mediates between the user and the socket.