begeman@mcc-db.UUCP (Michael Begeman) (03/26/85)
I use a network analysis program that takes 1.5 HOURS(!) of cpu time to load and preprocess a very large net. Each of the subsequent analysis queries take only a few minutes. How can I save the state of the process before logout and restore it later? I tried core-dumping it, but couldn't get adb to restart it correctly, and CSH kills any stopped jobs at logout. Restriction: I can't dink with the source...this has to be solved externally. Ideas, wiz? Gracias in advance. ------- It's sailing weather down here!!! Michael L. Begeman Microelectronics and Computer Technology Corp Software Technology Program Austin (where the sun always shines) Texas {ihnp4, gatech, seismo, noao, ctvax}!ut-sally!mcc-db!begeman
throopw@rtp47.UUCP (Wayne Throop) (03/30/85)
> I use a network analysis program that takes 1.5 HOURS(!) of cpu time > ... > Restriction: I can't dink with the source... > ... > Michael L. Begeman Microelectronics and Computer Technology Corp There are two solutions that occur to me. Both mean leaving the program running in the background, with connections left so that you can connect to it later. One method (by far the simpler one) is applicable under System V. It goes like this: To get the program rolling: $ /etc/mknod in p $ /etc/mknod out p $ nohup {your-command-line} <in >out 2>&1 & $ nohup sleep 40000 </dev/null >in 2>&1 & $ cat out & $ cat >in You are now talking to your program. Now, you can wait until the program has gotten to a stable state (no IO going on), and then logout. To get re-connected to the program when you login, $ cat out & $ cat >in To send EOF to the program, kill the sleep-ing process and the "cat >in" process. The other processes will come down gracefully. I have tested this method on a System V system with "cat" taking the place of {your-command-line}. The equivalent solution for BSD4.2 is more complicated. Using sockets instead of fifos implies that you must either modify your program to use connect instead of open, or you must write a program to mediate the connection to the socket. SO: the Berkeley method means writing two programs: - One to fork off {your-command-line}, create and bind a socket (so that it can be found after logout/login), and use select to transfer a datastream from the socket to a pair of pipes that connect to the {your-command-line} process. - The other program connects to the bound socket, and uses select to transfer a datastream from the terminal to this socket. I call these programs "create interactive demon", and "connect to interactive demon". I propose these interfaces (since I don't actually have these written). int_dem {socket-name} {command-line} con_dem {socket-name} With these two programs, the scenario under Berkeley becomes % int_dem foo {your-command-line} After which you can either use con_dem immediately, or log out and use con_dem after a subsequent login: % con_dem foo The behavior of these programs on encountering EOF on a pipe or a socket is left as an excersize for the implementor. BTW, if anybody here comes up with the code for these programs, I'll post them. -- Wayne Throopw at Data General, RTP, NC <the-known-world>!mcnc!rti-sel!rtp47!throopw