Seams I posted on the wrong chapter…

I've used my own State-Transition Paradigm for 15yrs now. I've been successful in keeping complexity down in my versions of financial telecommunication software (mostly stock exchanges), and Change management software

What I did was to extend the STD to do more. I did this by including incoming events, transitions, and outgoing events. This allows a lot more expression in the story. In fact it nearly tells the whole story. The transitions can be compiled into routines (or "Events" in your definition).

In my definition of STD an 'event' is something happening on the underlying socket (like a msg received), a user API routine call, or an 'internal event' being signalled.

Internal events are usually part of the of a transition on Object A, issuing an event on Object B.

The transitions are the hand coded routines. In some cases I partially generated them, and in other case I fully generated them.

I know this sounds weird, but think about how much code you could remove from nanomsg if your state diagrams looked like: http://westrick.com/Jerry/CubixSystem.pdf .

This is the method I invented to get a handle on the inherent complexity of async systems.

Be interested in what you think…

Oh, and yes, in this method, a socket can be assigned an STD per protocol, instead of one STD for all… Which seams to be the core of your problem.

When you use this system you need to loosen your hold on the name of the states.
The first draft of the STD you place the states you think will be there and start adding events and transitions. But a state is defined but what events it is waiting for, and usually the original name turns out to be misleading, and needs to be changed.

In the diagram present the API call cLogout() must be called to get to LogoffRequested.
(not shown in the diagram is the FIX UserLogoff msg sent out in cLogout(). Then a FIX response from the logout is required.

This defines the state, not the name (LogoffRequested) in the bubble!

I think something similar might be the way to get a handle on the complexity of nanomsg…

You will note that FIX msg events are in Blue and that the event is conditional to certain field values. The green represents function/subroutine calls those starting with lower case "c" are API calls from client, etc, etc

If you are going to tell a story, tell it well…

The pdf
The list of Lamport papers

The diagram seems to be essentially triples, ex: <FIN_WAIT_1, ACK, CLOSING>, more generally: <STATE, EVENT, STATE>.

(from the papres mentionned)

All of the code that I see that fails to follow this pattern ends out a tangled mess of uh… "logic". It's never really clear who is doing what or responsible for this or that.

Although the typical implementation is a bit less formal, these kinds of state machines *are* related to the finite state machines of automata theory, and that's a *good* thing. Formalizing things, at least to some degree, helps you think about them in a structured and well-understood way. That's because they're based on simple theoretical constructs, not in spite of it.

I think events are superior for several reasons:
1. They can be pretty easily logged. In your event dispatch simply log each event with its receiver.
2. They can have aspect-like rules attached. For instance: Any event which starts with 'set' should check the user who created it for authorization.
3. They can handle delegation by forwarding events to other objects. This is great for avoiding unnecessary inheritance.
4. Composition of events. Chain multiple events to fire in sequence.

Anyway, I am planning to write down my take on state machine implementation details in the next blog post once I have some time free. We can discuss it then.

Anyway, I was fed up with doing the same stuff all the time, so I wrote go-statemachine. I am going to use it for implementing objects that are supposed to act as small synchronous event loops, and that is basically what those state machines are, right? Feel free to comment on the library, it's not like written according to this article or super optimized, it is for my purposes. But I still think that it might be useful for someone. I wrote it like today, so it can and will change, but you know, it's there ;-)

Regards,
Ondra Kupka