plain_fsm - for beginners and purists

Ulf Wiger ulf.wiger@REDACTED
Sat Feb 7 01:30:37 CET 2004


I have checked in a behaviour/library in the Jungerl(*) called plain_fsm.
The idea is that you should be able to write "classic" erlang state 
machines
without having to give up support for OTP system messages (suspend, resume,
get_status, code_change).

(*) http://jungerl.sourceforge.net for those who have happened to miss it.

I would very much like some input.

Strange thing - I am pretty sure the checkin worked, but it doesn't appear
in the ViewCVS. Is anyone else able to see it?

Anyway, there's an example file in there, where I've added support for
system messages in the idle state:

idle(S) ->
     plain_fsm:extended_receive(
       receive
           a ->
               io:format("going to state a~n", []),
               a(S);
           b ->
               io:format("going to state b~n", []),
               b(S)
       after 10000 ->
               io:format("timeout in idle~n", []),
               idle(S)
       end).

The extended_receive/1 function is a pseudo function which is replaced
in a parse transform with receive clauses for system messages and parent
termination. This is (nearly) the only thing that has to be done in order
to make the process a good OTP citizen.

I have also added some examples comparing programming models, and 
attempting
to show what problems arise with run-to-completion event-based programming.
This you will find in the doc/ directory.

/Uffe
-- 
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.




More information about the erlang-questions mailing list