Signals, Forking, Events, and other Madness. 
Author Message
 Signals, Forking, Events, and other Madness.

Background: I've been working on a batch job application that queues up
several jobs and executes them one at a time in a separate dialog while
allowing the user to add and delete jobs from the queue.  I use fork and
exec (dangerous, I know) to run the jobs and catch the SIGCHLD signal when
the child process exits to update the queue dialog and spawn a new job, all
while continuing to process user events.  The application can also send
jobs to a network queue, but it sends those all at once, and I'm not
interested in the SIGCHLD signal from that, so I just do a system() call.

Whew.

My problem is, the function called by SIGCHLD is pretty complex, and
modifies a bunch of stuff, and could take user input from dialogs, and does
other things that could possibly result in the program hitting some
degenerate state if the function is called at the wrong time.  Ideally what
I'd want is something like this....

sub CalledFromSigChild {
   my($pid) = wait();

   }

... and then ...

sub CalledEverySoOften {

   while(defined($pid)) {
      if($pid == $rightpid) {
         # Spawn Next Job (setting $rightpid)
         # Update View
         }

      }
   }

...obviously, jobs won't be completing so fast that they become a problem
in this case, but even in that case the queue should empty quickly enough
to avoid any major complications.  My problem is how to schedule
CalledEverySoOften() so that it gets called often enough.  Can I place an
even on the event queue in CalledFromSigChild() so that it gets called in
the normal processing of events (which is what I'd like to do)?  Can I
schedule it to happen every so often in a way that won't affect
performance (I read something about Tk::DoWhenIdle, but haven't found any
examples)?

Any help is appreciated.

--

  |c-oo             http://www.*-*-*.com/ ~jason.m.sullivan
   \_-     "That's not music, that's just sound!" - J. David Fries



Fri, 05 Jul 2002 03:00:00 GMT  
 Signals, Forking, Events, and other Madness.

Quote:
> Background: I've been working on a batch job application that queues up
> several jobs and executes them one at a time in a separate dialog while
> allowing the user to add and delete jobs from the queue.  I use fork and
> exec (dangerous, I know) to run the jobs and catch the SIGCHLD signal when
> the child process exits to update the queue dialog and spawn a new job, all
> while continuing to process user events.  The application can also send
> jobs to a network queue, but it sends those all at once, and I'm not
> interested in the SIGCHLD signal from that, so I just do a system() call.

My college uses pvm to handle the batch part.

Quote:
> My problem is, the function called by SIGCHLD is pretty complex, and
> modifies a bunch of stuff, and could take user input from dialogs, and does
> other things that could possibly result in the program hitting some
> degenerate state if the function is called at the wrong time.  Ideally what
> I'd want is something like this....

It is very dangerous to do complex things in a signal handler.  (Read Stevens
:-) )

Quote:

> sub CalledFromSigChild {
>    my($pid) = wait();

>    }

> ... and then ...

> sub CalledEverySoOften {

>    while(defined($pid)) {
>       if($pid == $rightpid) {
>          # Spawn Next Job (setting $rightpid)
>          # Update View
>          }

>       }
>    }

Maybe a construct with repeat helps you?  

$top->repeat(5000,sub { CalledEverySoOften()});

The first parameter is the time in milliseconds. (5seconds)
Bjoern



Sat, 06 Jul 2002 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. signal handlers and system (others?)

2. where is Tk::Event::Signal

3. How to disable signals to fork processes

4. Kill Signals going to forked System command not Perl script

5. Perl Signals and forking server

6. Please help = Fork and Signals in perl 5.6 ,Win32 version

7. fork,wait,signal

8. POE 0.11: event driven state machines, also supports Perl/Tk and Event

9. HTML::Parser 3.07 text events vs token events

10. Processing other events while waiting for an event to happen

11. acting on non event-oriented events

12. file events vs. window events

 

 
Powered by phpBB® Forum Software