3.7 Special Considerations in BeeSoft Programming
The BeeSoft Scheduler assumes that computation occurs in small increments, for example, in response to particular events or as a part of a repeating "observe, act, re-observe, check, re-act" cycle. Lengthy computations are done in stages, with intermediate results and changes in state saved between computational sessions.
In between such sessions, the BeeSoft Scheduler tends to the demands of the external environment -- the robot itself. This makes sense because the robot is operating in a dynamic, swiftly-evolving environment, and cannot afford to be ignored while some computation crunches blithely away. The design of the BeeSoft Scheduler not only suggests this "incremental" approach to computation; it virtually requires it. All modules in a BeeSoft Scheduler-based application run in the same process, making your use of the Scheduler, as well as the integration of modules from disparate sources, much simpler.
The apparent downside? A callback cannot be pre-empted or forced to stop execution. If a callback either blocks or requests a calculation that cannot be completed within a relatively brief interval, the BeeSoft Scheduler might not be able to adequately satisfy the scheduling requests of all modules. As a consequence, robot performance might suffer.
In actual practice, this restriction has not proven too onerous. Indeed, the simplicity of the architecture it permits is a signal advantage in research and educational environments. Also, remember that since the physical robot is actually being controlled by a server in a different process, a flubbed schedule in a user-level program is hardly likely to be catastrophic.
