Pausing and un-pausing programs from a master program using kill

knobby67 · 01-11-2016, 08:04 AM

Hi All,
I'm running a master program that in turn runs other hi res graphics demos. Basically this master system is used as it takes 45 secs + to load in each demo. So rather than load each demo each time, I load in a demo, pause it, load in the next. When they are all loaded in the master program loops allowing the user to select a demo, when they select the master is paused and the demo is unpaused.
This appears to work at first however every so often, sometimes after a few tries sometimes after a long long time it locks up. I think the pause unpause of processes are not syncing, multi core issue? So my code flow is, start the master program

Code:

load in demo 1.  When it's loaded unpause master
pause master.
load in demo N   When it's loaded unpause master 
pause master


do
user selects demo so it's unpaused -> in demo user can exit which pauses demo and unpauses master.   
pause master
while

I'm using kill from system calls to pause unpause eg

Code:

void ProcessControl_Class::pause_local_process( void )
{
std::string command = "kill -STOP ";
command += std::to_string( process_id );

system( command.c_str( ) );

}

void ProcessControl_Class::unpause_external_process( std::string process )
{
std::string command = "kill -CONT ";
command += std::to_string( get_external_process_id( process ) );

system( command.c_str( ) );

}

I've been reading last night and came across the following functions waitpid() execl(), I was thinking of trying these, but they seem to be used only with forked child processors. So I'm a bit confused. Can I used these to replace the kill -STOP -CONT and system("./demo")?;

sundialsvcs · 01-11-2016, 12:55 PM

I suggest that, rather than trying to freeze the threads/processes "externally" ... which would leave them in an uncertain state ... you should design them so that they expect to receive signals, say SIGUSR1 and SIGUSR2, which would mean "please pause" and "please resume," respectively.

Upon receipt of the appropriate signal, the processes would enter or leave a "paused" state ... whatever such a thing means to them ... and, most importantly, they would be the ones doing it. They continue to be alive-and-well, and they continue to be masters of their own affairs.

I envision that perhaps each program has a "state" variable which might include such states as (RUNNING, PAUSING, PAUSED, RESUMING), and a condition-variable upon which the process can "hard wait" while PAUSED. (The variable is signaled by the SIGUSR2 handler.) So, the process would "fall deeply asleep" while waiting to be continued, but it would handle all state-transitions cleanly and on its own terms.