事件处理的扭曲模式

Question

(Some assistance in forming this question in a better form is welcome as well)

I'm looking at twisted for implementing a piece of asynchronous software that has absolutely nothing to do with the internet. I've also obtained a copy of Twisted Network Programming Essentials which was rather disappointing. It, and pretty much every other tutorial out there, seems to treat twisted as a networking client only, using built-in event handlers and silently using built in glue-code which is difficult to generalize.

For context, my application would want to talk to hardware devices using serial / pyserial and provide a gui using Qt. I'm not even close to the point where I would start worrying about the Qt reactor (which looks to be yet another promise of a can of worms) or porting to windows.

For a start, I'm using a twisted select reactor, to which I've added a Protocol + FileDescriptor that handles udev events. What I have so far works, in that udev events trigger a function in the protocol (eventReceived). The following is the protocol and the way it's added to the reactor :

class UdevMonitorListener(Protocol):
    def __init__(self, _reactor=None):
        if _reactor is not None:
            self._reactor = _reactor
        else:
            self._reactor = reactor
        self.subsystem = 'tty'
        self.monitor = None

    def startListening(self):
        logger.info("Starting UdevMonitorListener")

        self.monitor = UdevMonitor(self._reactor, self, self.subsystem)
        self.monitor.startReading()

    def eventReceived(self, action, device):
        if device in connected_devices.udev_ports:
            if action == u'remove':
                connected_devices.remove_by_udev_port(device)
        if action == u'add':
            if is_device_supported_from_udev_port(device):
                if device not in connected_devices.udev_ports:
                    connected_devices.append_by_udev_port(device)


def init(_reactor=None):
    monitor_protocol = UdevMonitorListener(_reactor)
    monitor_protocol.startListening()

The function init() is called by a reactor.callWhenRunning() just before reactor.run() . The eventReceived function is called as expected by the FileDescriptor. I can add that code here as well if it helps.

What I would like is for eventRecieved to trigger some sort of event in the reactor which something else can react to. This code shouldn't care who's consuming this, and that code shouldn't care who's generating it. These events would be far and few between, and I can't seem to find an interface that'll be able to do this cleanly. The events are expected t come relatively infrequently, but they will never 'end'. If a deferred is to be used, it would have to have some way of 'refreshing' itself to wait for the next event. What are the usual patterns for handling events such as this?

Edit:

For the sake of posterity and anyone else looking, the rest of the code :

(from https://gist.github.com/dpnova/a7830b34e7c465baace7 )

class UdevMonitor(FileDescriptor):
    """
    File Descriptor for pyudev.Monitor.
    @see: U{http://packages.python.org/pyudev/api/monitor.html}.
    """
    def __init__(self, _reactor, protocol, subsystem=None):
        FileDescriptor.__init__(self, _reactor)

        # Set up monitor
        context = pyudev.Context()
        self.monitor = pyudev.Monitor.from_netlink(context)
        if subsystem:
            self.monitor.filter_by(subsystem=subsystem)

        # Connect protocol
        assert isinstance(protocol, UdevMonitorListener)
        self.protocol = protocol
        self.protocol.makeConnection(self)

    def fileno(self):
        """
        Return monitor's file descriptor.
        """
        return self.monitor.fileno()

    def startReading(self):
        """
        Start waiting for read availability.
        """
        logger.debug("starting udev monitor fd")
        self.monitor.start()
        FileDescriptor.startReading(self)

    def doRead(self):
        """
        An event is ready, decode it through Monitor and call our protocol.
        """
        logger.debug("udev reports event available")
        event = self.monitor.receive_device()
        if event:
            action, device = event
            self.protocol.eventReceived(action, device)

    def writeSomeData(self, data):
        raise IOError("You can't write to a udev Monitor")

Or the full module including connected_devices and searching for devices is up at https://gist.github.com/chintal/2511459c02a9767deb5d

Answer 1

What I would like is for eventRecieved to trigger some sort of event in the reactor which something else can react to. This code shouldn't care who's consuming this, and that code shouldn't care who's generating it.

The pattern for doing this that's widely used both in Twisted and by Twisted-using applications is “make a function call” (perhaps a method call).

The reactor itself does not make a good single-process message bus. There's been little motivation to try to make it into one because function calls by themselves work pretty well in the general case and when you get to the less common, specialized cases where they don't it's actually really hard to make something good (and once you do, you've still only serviced a tiny fraction of the possible audience of Twisted).

Your code already includes an example of the kind of thing I'm talking about. UdevMonitor calls UdevMonitorListener.eventReceived when (I'm guessing) some kind of event comes out of the udev system.

Just repeat this. Give your UdevMonitorListener a reference to another object and call some method on that object at the appropriate time. For example:

class UdevMonitorListener(object):
    def __init__(self, device_listener, _reactor=None):
        ...
        self.device_listener = device_listener

    def eventReceived(self, ...)
        ...
        self.device_listener.some_device_thing_happened(...)

Also note I changed the base class to object . Protocol is a somewhat handy base class for IProtocol implementations - but that's not what UdevMonitorListener is, so Protocol isn't a good choice of base class.