Leaderboard

Thought I'd show an example of "complexity" of a framework, according to my way of thinking, by comparing the priority messages of the NI Actor Framework and the DQMH: Looks the same from an API level (they even use similar icons). Let's look inside; here is the relevant code section for priority messages for the AF: Yikes! And here is the same for DQMH: Ah, much simpler. Now we can see which framework involves more complexity: the DQMH. Wait, what, you say? Isn't the obvious complexity of the AF implementation mean the AF involves more complexity? Well, no, because I, as User of a framework, care nothing about the implementation, I care about application I am building with these APIs. So let's consider the task of sending three high-priority messages, A then B then C. In what order will the three messages be received and acted on? With the Actor Framework the order will be A, then B, then C, ABC, always. With the DQMH we have: 1) if the receiver can execute them faster than they are sent, the order will be ABC 2) if the receiver is handling another message the order will be CBA (as we place on the front of the queue) 3) if the receiver is idle, but executing A takes time (allowing C to get before B), the order will be ACB 4) if busy but finishes after B is sent but before C is sent, the order is BCA 5) as (4) but B is finished executing before C sent, ther order is BAC Thus with the DQMH there are 5 possible orderings of execution, with the probability of the various orderings highly dependant on timing of not-directly-related bits of code (other messages being sent). At best, this is counter-intuitive and potentially confusing during debugging. At worst, one combination is a rare race condition that doesn't show up during testing and causes near-impossible-to-debug errors in deployed code. So that is an example of complexity, and it is certainly accidental, as the DQMH designers did not intend unpredictability of message-handling order when they used enque-in-front as message "priority".