2

I'd asked a very similar question earlier, but the project scope is quickly growing beyond where signals can get me (I think). Basically, my program will be doing stuff on three different intervals; one function every 15 seconds, one function at a configurable interval (5 to 60 seconds, generally), and one function every hour or two.

From an intuitive standpoint, it seems like multiple signal.signal() calls with separate functions wouldn't get me very far: an ITIMER_REAL timer only issues one signal -- SIGALRM, and thus there would be no way to differentiate which itimer is issuing the signal. Since the 15-second interval function needs to run regardless of what might be going on with the other functions, this leaves me with the choice of multithreading or multiprocessing.

I'm leaning towards multiprocessing, in hopes I can just spawn three child processes, each with their own signal/itimer intervals, and let them each do their work at their leisure. Is this feasible? If not, what would be the best way to have these three functions run at their desired intervals?

Community
  • 1
  • 1
Doktor J
  • 1,058
  • 1
  • 14
  • 33

1 Answers1

3

This is feasible, but if the three loops aren't doing any heavy computation (needing multicore power), you could just as well launch three threads.

Or, you could let a single loop handle this with a priority queue. Push (time, task) pairs onto the queue, where task is some description of the task to be done. Then, in a loop:

  • pop an item
  • wait until the specified time is due
  • perform the task
  • reschedule the task after 5 secs, 15 mins, 2 hours, whatever, by pushing a new item onto the queue.
Fred Foo
  • 355,277
  • 75
  • 744
  • 836
  • My concern is blocking; one of the tasks involves accessing a web site, and if the site is not available, i don't want the 15-second-interval task to get held up because of it. Also, I was thinking MP instead of MT for my original idea because the signal documentation (http://docs.python.org/library/signal.html) indicates that attempting to call signal.signal() from threads other than the main thread will raise an error. – Doktor J Mar 10 '12 at 15:27