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.