Thread-based or event-based?

Thread-based or event-based?

Posted Mar 1, 2007 9:29 UTC (Thu) by wahern (subscriber, #37304)
Parent article: Thread-based or event-based?

State machines aren't difficult. For complex tasks they really simplify things. As code flow branches into a gazillion function calls you eventually just get lost. Wrapping your head around things is near impossible.

With a state machine, typically done w/ a switch statement and/or function table, you can very clearly see all the possible points of execution in a small amount of code. In terms of maintainability it cannot be beat, at least not in the imperative and OOP world.

OTOH, state machines require careful thought at the outset. And sometimes you connect state machines which regular procedural flow (i.e. one state machine in a stream filter, effectively embedded in a large state machine doing something more application oriented).

I use state machines and event-oriented programming mostly. But I also have a threaded task library (basically a thread pool which dispatches from and returns to the main thread using callbacks) which I use so I can "plug-in" certain blocking tasks into a state machine. And of course I often have multiple state machines arranged like mentioned previously.

As to whether we need kevent? Of course we do. epoll() is a hack, like dnotify was in relation to inotify; in this case too narrowly concerned w/ sockets. Actually, we really need kqueue, and maybe that's exactly what Igno doesn't want to see. Which is a shame, because the kqueue interface very nicely unifies the hodge-podge components of the Unix resource and process model--hodge-podge, yes, but not necessarily ill-gotten, and entirely redeemed w/ kqueue.

---

(Log in to post comments)