Interactive Background Processes

[Joe Bob Willie]

In article <Jul.2.05.40.52.1988.8275 at porthos.rutgers.edu> webber at porthos.rutgers.edu (Bob Webber) writes:
>In article <16365 at brl-adm.ARPA>, kvancamp at ardec.arpa (Ken Van Camp) writes:
>> 
>> 	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 have no problem backgrounding a process, getting a message saying that
>it has stopped waiting for terminal input and foregrounding it to talk
>to it.  On the Suns, gcore will get you a core dump of a running process
>allowing you to interogate it using your favourite debugger. So your problem
>should go away now that bsd and svid are merging.

arggggg.  under certain version of at&t unix it is possible to do something
like job control using the shell layer manager.  this would let ken run
a ray tracer or whatever in the foreground and switch layers to do another
task.

unfortunately, not all of the modern unix implementations have sxt's and
the shell layer manager.  for example, the plexus doesn't have any of
those things.  the wyse, running xenix, does, but only has one control
sxt so only one instance of shl can be running.

no usg's i'm aware of support gcore.  not that it is hard to do, just
pick up the u-page and write it and the data segment into a file.  also,
unless ken wants to spend the money to buy new gear and new software,
the problem doesn't go away 8-(.

- john.
-- 
 Joe Bob Willie                                             Big "D" Oil and Gas
 UUCP: ...!killer!rpp386!jfh                            jfh at rpp386.uucp :DOMAIN
 **** Trivia question of the day: VYARZERZIMANIMORORSEZASSEZANSERAREORSES? ****
 "You are in a twisty little maze of UUCP connections, all alike" -- fortune