kvancamp@ardec.arpa (Ken Van Camp) (07/02/88)
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.
Interactive I/O in a long simulation is often desirable. Typical
uses may include:
(1) Interrogation of the model, to determine the current state of
computation. This may include a graphical interface.
(2) Modification of the model "on the fly", including rezoning, dropping
elements, changing a maximum or minimum simulation time or time step,
redefining materials, and many others.
(3) Giving the user and/or system administrator the chance to prematurely
abort a simulation without losing results. Typically, if a system
must be shut down while background processes are in progress, the
simulation will be lost and will have to be restarted from scratch.
Since many large simulation codes already possess the capability to
write a restart file, it would make more sense to allow system
administrators an easy way to alert all background processes of an
imminent shutdown, so the program can shut itself down "gracefully".
The purpose of this message is twofold: (1) I would like to hear
from other programmers who have given thought to this problem, and possibly
devised solutions; and (2) If you are interested in the subject but haven't
given it much thought, you are welcome to try out my first attempt at a set
of "generic" background I/O routines (callable from either C or Fortran).
I call my package "BGio", and you can get a copy of the shar file (complete
with short working examples, about 50 Kbytes long) by sending e-mail to me.
I have used BGio in EPIC-2, a finite element program for large-strain impact
simulations. It has also been tested on three different Unix systems: a
Silicon Graphics Iris (System V), DEC 8600 (Ultrix), and an Integrated
Solutions (4.3 BSD).
--Ken Van Camp
ARPANET or BITNET: kvancamp@ARDEC.ARPA
USENET: uunet!ardec.arpa!kvancamp
I would understand life much better
if someone would just show me the source code.webber@porthos.rutgers.edu (Bob Webber) (07/02/88)
In article <16365@brl-adm.ARPA>, kvancamp@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. ---- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
valdis@sun.mcs.clarkson.edu (07/03/88)
Date: Fri, 1 Jul 88 15:59:05 EDT From: Ken Van Camp <kvancamp@ardec.arpa> 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. Hmm. Sounds to me like he wants a windowing system. Run the sucker in a window, and run other windows around it. Use X11, or Suntools. If you're stuck on ascii devices, there's 'screen' in the comp.sources.unix archives. Valdis Kletnieks Sr. Systems Programmer Clarkson University
haugj@pigs.UUCP (Joe Bob Willie) (07/06/88)
In article <Jul.2.05.40.52.1988.8275@porthos.rutgers.edu> webber@porthos.rutgers.edu (Bob Webber) writes: >In article <16365@brl-adm.ARPA>, kvancamp@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@rpp386.uucp :DOMAIN **** Trivia question of the day: VYARZERZIMANIMORORSEZASSEZANSERAREORSES? **** "You are in a twisty little maze of UUCP connections, all alike" -- fortune
les@chinet.UUCP (Leslie Mikesell) (07/07/88)
In article <237@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >>> ... Unfortunately, under Unix, selecting >>> background processing precludes interactivity in the software. > >unfortunately, not all of the modern unix implementations have sxt's and >the shell layer manager. If all you need is to send an occasional command to a running program you can just create a FIFO and connect the input of the program to it. Then just write the commands to the FIFO as needed. Knowing *when* the commands are needed is a different problem... Les Mikesell
wilber@alice.UUCP (07/07/88)
As a non-wizard (posting under false pretenses, I guess) it seems to me that
if you have a version of Unix without job control or layers or the like the
"poor man's solution" to this problem is to fire up Emacs, make as many shell
buffers as you need, and run whatever you want in each one. Of course the
background process can't keep running after you log out.
Bob Wilber Work: UUCP: {allegra, mtune, ihnp4}!gauss!wilber
ARPA: wilber@research.att.comsteve@edm.UUCP (Stephen Samuel) (07/09/88)
From article <Jul.2.05.40.52.1988.8275@porthos.rutgers.edu>, by webber@porthos.rutgers.edu.UUCP: > In article <16365@brl-adm.ARPA>, kvancamp@ardec.arpa (Ken Van Camp) writes: >> >> When running large, computationally-intensive programs (such as .... >> perform other tasks, logout, etc. Unfortunately, under Unix, selecting >> background processing precludes interactivity in the software. You can still open a specific TTY... If you do not orphan the task, then you can still query /dev/tty, else you can find out which tty to talk to and open(3) /dev/ttyxxx directly and talk to it.. -- ------------- Stephen Samuel Disclaimer: You betcha! {ihnp4,ubc-vision,mnetor,vax135}!alberta!edm!steve BITNET: USERZXCV@UOFAMTS
jfh@rpp386.UUCP (John F. Haugh II) (07/09/88)
In an earlier posting I was discussion background processes in 5.0 and mentioned how not all implementations were capable of running multiple background jobs. Someone from SCO sent me a letter and here is the text of it: +---- |> 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. |> |>- john. |>-- | | If you want to run more than one instance of shell layers, | run configure(C) and raise NSXT from its default of 1. | No inherent limitation here. | --amy +---- -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
woods@gpu.utcs.toronto.edu (Greg Woods) (07/10/88)
If you are writing a new program, or you have source for your
application, the AT&T UNIX System Toolchest may be of help.
(1-201-522-6900, login: guest)
A product called "BPTAP-Background Process Terminal Access Package" is
available in source form for $250. It is a set of four functions that
can connect a background process with the user's current terminal for
the purpose of sending messages or output, and receiving replies.
I've not used this product, and have no affiliation with AT&T. I just
happened across it in my AT&T catalogue the other day, and I can't
recall anyone mentioning it yet.
--
Greg Woods.
UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods
VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canadawoods@gpu.utcs.toronto.edu (Greg Woods) (07/13/88)
In article <8029@alice.UUCP> wilber@alice.UUCP writes: >As a non-wizard (posting under false pretenses, I guess) it seems to me that >if you have a version of Unix without job control or layers or the like the >"poor man's solution" to this problem is to fire up Emacs, make as many shell >buffers as you need, and run whatever you want in each one. Of course the >background process can't keep running after you log out. > >Bob Wilber Work: UUCP: {allegra, mtune, ihnp4}!gauss!wilber > ARPA: wilber@research.att.com Unfortunately, a Unix without job control, layers, or such will not provide the system facilities required for emacs to do the same. Fortunately, one of these "features" usually exists in every version of Unix, though that doesn't mean emacs will work with it properly. Unfortuantely, only a true window manager for X or NeWS, or layers (not shell-layers) on a DMD terminal, or something similar, are easy enough to use. None of these are usefull on a dumb terminal at 1200 baud, though layers is nearly so, it's just the terminal isn't very cheap nor dumb. -- Greg Woods. UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
wilber@alice.UUCP (07/14/88)
Greg Woods writes: >In article <8029@alice.UUCP> wilber@alice.UUCP writes: >>As a non-wizard (posting under false pretenses, I guess) it seems to me that >>if you have a version of Unix without job control or layers or the like the >>"poor man's solution" to this problem is to fire up Emacs, make as many shell >>buffers as you need, and run whatever you want in each one. Of course the >>background process can't keep running after you log out. > >Unfortunately, a Unix without job control, layers, or such will not >provide the system facilities required for emacs to do the same. The Unix running on my 3b1 (a somewhat bowdlerized variant on SYS V 2.0) definately does not have job control (sigh) and, although there may be some version of layers available for this box, I don't have it. Nonetheless my Emacs (GNU, version 18.49) runs multiple shell buffers just fine, thank you. It communicates with the shell processes via ptys. (The pty drivers I use are a public domain version snarfed off the net.) I haven't looked at the code to see the details of how Emacs does it, but it works. I suspect that whenever Emacs has nothing better to do it simply polls the screen to see what to pass to the ptys and polls the ptys to see what to put on the screen, but like I said, I haven't bothered checking the code. >Fortunately, one of these "features" usually exists in every version of >Unix, though that doesn't mean emacs will work with it properly. See above. Emacs doesn't need job control or layers to handle multiple shells, although at least on the 3b1 it does need ptys (attempting to link up with shell processes via pipes didn't work). >Unfortuantely, only a true window manager for X or NeWS, or layers (not >shell-layers) on a DMD terminal, or something similar, are easy enough >to use. None of these are usefull on a dumb terminal at 1200 baud, >though layers is nearly so, it's just the terminal isn't very cheap nor dumb. Emacs isn't that tough to figure out -- no mice to slow you down, no cute little bit mapped pictures of trash cans or rolodexes to confuse and distract you. Remember, Emacs, like Unix, is asymptotically user friendly. And it can be used at 1200 baud if you're desperate, although that is admittedly very painful. (I didn't realize you were stuck with a 1200 baud link.) Bob Wilber Work: UUCP: {allegra, mtune, ihnp4}!gauss!wilber ARPA: wilber@research.att.com
aeusemrs@csuna.UUCP (Mike Stump) (07/14/88)
In article <1988Jul13.001105.29472@gpu.utcs.toronto.edu> woods@gpu.utcs.UUCP (Greg Woods) writes: -In article <8029@alice.UUCP> wilber@alice.UUCP writes: --As a non-wizard (posting under false pretenses, I guess) it --seems to me that if you have a version of Unix without job --control or layers or the like the "poor man's solution" to --this problem is to fire up Emacs, make as many shell --buffers as you need, and run whatever you want in each --one. Of course the background process can't keep running --after you log out. --Bob Wilber -Unfortunately, a Unix without job control, layers, or such -will not provide the system facilities [sic] required for -emacs to do the same. - Greg Woods. One rule of of thumb, never rip someones head off, unless you are sure you are right. (Because someone like myself, in defense of a person like Bob, might rip your head off.) Bob is perfectly correct in this case, and does not need correcting. If I understand you correctly, you are just plain wrong, if I do not, I would like a clarification on the statement you made. -- Mike Stump, Cal State Univ, Northridge Comp Sci Department uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!csuna!aeusemrs
aglew@urbsdc.Urbana.Gould.COM (07/14/88)
>Date: Fri, 1 Jul 88 15:59:05 EDT >From: Ken Van Camp <kvancamp@ardec.arpa> > > 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.
aglew@urbsdc.Urbana.Gould.COM (07/14/88)
..> Interaction with backgrounded processes It's also possible to use other forms of IPC, such as messages or semaphores in combination with a FIFO; the key is that some form of asynchronous notification is usually required, although splitting the backgrounded process into two can sometimes get around that.
woods@gpu.utcs.toronto.edu (Greg Woods) (07/20/88)
In article <8037@alice.UUCP> wilber@alice.UUCP writes: >Greg Woods writes: >>In article <8029@alice.UUCP> wilber@alice.UUCP writes: >>>[message expressing desire for interactive background processes] >> >>Unfortunately, a Unix without job control, layers, or such will not >>provide the system facilities required for emacs to do the same. > >The Unix running on my 3b1 (a somewhat bowdlerized variant on SYS V 2.0) >definately does not have job control (sigh) and, although there may be some >version of layers available for this box, I don't have it. Nonetheless my >Emacs (GNU, version 18.49) runs multiple shell buffers just fine, thank you. >It communicates with the shell processes via ptys. (The pty drivers I use are >a public domain version snarfed off the net.) .... That's cheating! ;-) What I meant by "layers" was shl, and that to implement it you must (?) have pty's or sxt's. Jove on Xenix can't do interactive background tasks. I thought about trying the pty driver, but I'll be working with SVR3 soon, so I shouldn't need them any more. >>Fortunately, one of these "features" usually exists in every version of >>Unix, though that doesn't mean emacs will work with it properly. > >See above. Emacs doesn't need job control or layers to handle multiple shells, >although at least on the 3b1 it does need ptys (attempting to link up with >shell processes via pipes didn't work). No, but it does need the facilities used by shell layers, see above. :-) >>Unfortuantely, only a true window manager for X or NeWS, or layers (not >>shell-layers) on a DMD terminal, or something similar, are easy enough >>to use. None of these are usefull on a dumb terminal at 1200 baud, >>though layers is nearly so, it's just the terminal isn't very cheap nor dumb. Maybe someone will write (free) layers software for a PC? (hint hint...) As a matter of fact, it should come "free" with Unix. There are lots of PCs. >Emacs isn't that tough to figure out -- no mice to slow you down, no cute >little bit mapped pictures of trash cans or rolodexes to confuse and distract >you. Remember, Emacs, like Unix, is asymptotically user friendly. And it can >be used at 1200 baud if you're desperate, although that is admittedly very >painful. (I didn't realize you were stuck with a 1200 baud link.) I didn't say I don't like emacs! In fact I use it at 1200 baud nearly every day. ;-) Can we all say ISDN? >Bob Wilber Work: UUCP: {allegra, mtune, ihnp4}!gauss!wilber > ARPA: wilber@research.att.com -- Greg Woods. UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
woods@gpu.utcs.toronto.edu (Greg Woods) (07/20/88)
In article <1280@csuna.UUCP> I write: >-Unfortunately, a Unix without job control, layers, or such >-will not provide the system facilities [sic] required for >-emacs to do the same. >- Greg Woods. > >One rule of of thumb, never rip someones head off, unless >you are sure you are right. (Because someone like myself, >in defense of a person like Bob, might rip your head off.) I don't understand where you are comming from. I wasn't sniping him, I tried to answer his question, AND complain about the general state of affairs. >Bob is perfectly correct in this case, and does not need >correcting. If I understand you correctly, you are just >plain wrong, if I do not, I would like a clarification on >the statement you made. Since I didn't want to go in to the requirements for implementing all of these things, I tried to make a simple statement. I didn't want to consider things like homemade PTY or SXT drivers and such. USUALLY a system that has the "facilities" [system calls / drivers] for implementation of such features will also have some user-level commands for exploiting these facilities, ie. shl will be there if you have sxt's, and systems with pty's [nice for emacs] will ususally have job-control facilities built into the shell as well. BTW: Emacs may still not work with interactive processes on systems that have no PTY's or Streams, or multiplexed I/O. Again, remember I was making a general statement, and I wanted it to apply to the generally available systems that the perpetrator of the question, and readers of the reply, are likely to run across. >Mike Stump, Cal State Univ, Northridge Comp Sci Department >uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!csuna!aeusemrs -- Greg Woods. UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
allbery@ncoast.UUCP (Brandon S. Allbery) (08/02/88)
As quoted from <1988Jul19.223111.3644@gpu.utcs.toronto.edu> by woods@gpu.utcs.toronto.edu (Greg Woods): +--------------- | Since I didn't want to go in to the requirements for implementing all of | these things, I tried to make a simple statement. I didn't want to | consider things like homemade PTY or SXT drivers and such. USUALLY a +--------------- Are add-ons to SVR2 as made by various resellers exempt from this? Because they can easily lead to the same situation: vendor X adds ptys but not job control, and voila! emacs has interactive subprocess windows. I have my doubts that layers can be used for emacs unless ptys can be multiplexed they way terminals are -- of course, to be orthogonal with ttys controlling ptys *should* be able to be multiplexed.... +--------------- | system that has the "facilities" [system calls / drivers] for | implementation of such features will also have some user-level commands | for exploiting these facilities, ie. shl will be there if you have | sxt's, and systems with pty's [nice for emacs] will ususally have | job-control facilities built into the shell as well. BTW: Emacs may | still not work with interactive processes on systems that have no PTY's | or Streams, or multiplexed I/O. +--------------- While layers requires sxt's, there is no requirement that ptys and job control go together; I have seen systems with job control but no ptys and systems with ptys but no job control. I think you're trying to argue for the use of "pure" Unix (AT&T or BSD), in which case you must absolutely hate what Sun and AT&T are doing to your pure Unicen right now.... ;-) -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc