Statechart timer extension and new version of visualizer
Hi, I have implemented timers for library Boost Statechart. It was tested only on Linux because it uses POSIX threads. It is extension that replaces fifo_scheduler and fifo_worker with only one class Scheduler. That means that it is suitable only for asynchronous state machines. The source codes with example and short description can be downloaded here: https://www.dropbox.com/s/ubtep8f7hs6g5xl/boostTimers.tar.gz I would like to also inform you about new version of Boost Statechart viewer. Now it is plugin for compiler Clang and it was tested vitw version 3.0 and higher - (mostly tested using version 3.1). You can find more information and news about it on the web page of this project where you can also download the source codes and see some examples of the output pictures. http://rtime.felk.cvut.cz/statechart-viewer/ Best regards Petr
I have implemented timers for library Boost Statechart. It was tested only on Linux because it uses POSIX threads. It is extension that replaces fifo_scheduler and fifo_worker with only one class Scheduler. That means that it is suitable only for asynchronous state machines.
The source codes with example and short description can be downloaded here: https://www.dropbox.com/s/ubtep8f7hs6g5xl/boostTimers.tar.gz
Just out of curiosity: what's the design rationale of putting FSM-independent event generation logic (like timings) into the FSM itself? It what cases it would be better solution than putting timers outside the FSM? Thanks.
Dne 15.5.2013 20:06, Igor R napsal(a):
I have implemented timers for library Boost Statechart. It was tested only on Linux because it uses POSIX threads. It is extension that replaces fifo_scheduler and fifo_worker with only one class Scheduler. That means that it is suitable only for asynchronous state machines.
The source codes with example and short description can be downloaded here: https://www.dropbox.com/s/ubtep8f7hs6g5xl/boostTimers.tar.gz
Just out of curiosity: what's the design rationale of putting FSM-independent event generation logic (like timings) into the FSM itself? It what cases it would be better solution than putting timers outside the FSM?
Thanks. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Hi,
the reason is simple. We use statechart library for robot control and it is better to have timers inside library for us. It shorten the code and all state machines and timers can run in one thread. Petr
participants (2)
-
Igor R -
Petr Silhavik