Cooperative multithreading with generators and signal handling (Python recipe) by Brian Bush

ActiveState Code (http://code.activestate.com/recipes/162764/)

Cool Idea! Minor Changes... i like this idea a lot! i've made a few cosmetic changes:

moved the 'import time' statement to the top of the module. i didn't see any need to execute the import on every call to 'delay'.

replaced every 'True' with 1 and 'False' with 0. the change should make the code backward compatible with older Python versions.

replaced the 'self.thread=[]' statement in GenericScheduler.__init__ with an assigment to the 'thread' parameter. i favor allowing clients to specify as many attributes as possible.

moved the try/except block inside the while loop in GenericScheduler.scheduler.

from __future__ import generators

import signal
import time

# An implementation of cooperative multithreading using generators
# that handles signals; by Brian O. Bush

# credit: based off an article by David Mertz
# http://gnosis.cx/publish/programming/charming_python_b7.txt

def empty():
    """ This is an empty task. """
    while 1:
        print ""
        yield None

def delay(duration):
    while 1:
        print "" % duration
        time.sleep(duration)
        yield None

class GenericScheduler:
    def __init__(self, threads):
        self.shutdownRequest = 0
        self.threads = threads
        signal.signal(signal.SIGINT, self.shutdownHandler)

    def shutdownHandler(self, n, frame):
        """ Initiate a request to shutdown cleanly on SIGINT."""
        print "Request to shut down."
        self.shutdownRequest = 1

    def scheduler(self):
        while 1:
            try:
                map(lambda t: t.next(), self.threads)
                if self.shutdownRequest:
                    break
            except StopIteration:
                break


if __name__== "__main__":
    ts = [delay(1), delay(2), empty()]
    s = GenericScheduler(ts)
    s.scheduler()

as i said, the changes are mostly cosmetic. thanks for this recipie, i'm sure i'll use it!

More "improvements" Since the code already uses the generators feature, it's pretty damn safe to assume that True and False exist. Moreover, anyone who has read the "Python Regrets" presentation from Guido (our fearless leader), will know to use the "list-builder" notation in preference to "map". (The generated code is actually faster, too!) Here are my picky changes:

from __future__ import generators

import signal
import time

# An implementation of cooperative multithreading using generators
# that handles signals; by Brian O. Bush

# credit: based off an article by David Mertz
# http://gnosis.cx/publish/programming/charming_python_b7.txt

def empty():
    """ This is an empty task. """
    while True:
        print ""
        yield None

def delay(duration):
    while True:
        print "" % duration
        time.sleep(duration)
        yield None

class GenericScheduler:
    def __init__(self, threads):
        self.shutdownRequest = False
        self.threads = threads
        signal.signal(signal.SIGINT, self.shutdownHandler)

    def shutdownHandler(self, n, frame):
        """ Initiate a request to shutdown cleanly on SIGINT."""
        print "Request to shut down."
        self.shutdownRequest = True

    def scheduler(self):
        while True:
            try:
                [ thread.next() for thread in self.threads ]
                if self.shutdownRequest:
                    break
            except StopIteration:
                break


if __name__== "__main__":
    ts = [delay(1), delay(2), empty()]
    s = GenericScheduler(ts)
    s.scheduler()

Re: More "improvements" Regardless of Regrets Guido may have, there doesn't appear to be a need to build a list of results from calling each thread / generator's next() method. So instead of using map() or "list-builder" notation, all that's needed is simply:

for thread in self.threads: thread.next()

in the scheduler() method.

In IMHO the above is the most explicit statement of what needs and is being done (and is probably even faster, since it doesn't bother building a throw-away list nor incur any unnecessary function / method-call overhead).

BTW, some of the contents of the print statements in the original recipe's print statements do not show up in either commentator's code -- specifically those that contained text that looked like html tags.

For example, the

print "<sleep %d>" % duration

statement became

print "" % duration

which will cause a

TypeError: not all arguments converted

interpreter error to occur when it's run.

FWIW, to put literal "<" and/or ">" characters in comments here, they need to be replaced with their HTML character entity reference names, which are "&lt;" and "&gt;" repectively (sans the quotes). HTH.