Concurrent Modules for Octave

About | Details | Examples | API | Status | Download


GNU Octave is a high-level language for numerical computation with a syntax very similar to Mathworks' Matlab. The interaction between Octave's plots and the interpreter are currently very limited and there is no possibility to create graphical widget that could be used to create user-friendly interfaces. Octave being expandable, there exist several packages (provide links) that improve this situation.While most of the graphics related projects for Octave target an improved plotting capability, few provide the creation of GUIs. One prerequesite to support the creation and the use of graphical widgets is to make Octave handle user triggered "asynchronous" events.

Concurrent Modules for Octave, or CMO for short, is a GPL'ed project that aims to provide a framework to develope external modules that will:

  • run concurrently with Octave in separate threads without blocking Octave's input loop;
  • listen to Octave and respond to some module-defined commands (e.g. create a plot);
  • send events to Octave. Octave will check for events on its internal input loop or when it executes some specific commands (e.g. while pausing).
True asynchroneous event handling is not implemented, but it is believed that polling for the events while waiting for a user input or while processing some specific commands is sufficient.



CMO consist of three main parts:
  • a common set of functions to handle library initialization, modules handling and event processing (;
  • a cmo_module_interface class that is responsible to communicate with the module and to manage the registered events specific to the module (;
  • a cmo_module abstract class that is to be used as the base class to derive specific modules (like a GUI module). The user must implement a small set of virtual functions to be able to communicate with Octave. The to be implemented functions concerns the initialization of the module (starting its main loop), exiting the module (quitting its main loop), enabling and disabling events and executing module-specific commands (cmo-module.h)
Other helper classes are obviously used, such the cmo_event class that identifies an event and its associated cmo_callback class, and the cmo_command_interface responsible for the command transfer between Octave and the module.

Initialization and events polling

When initialized, CMO adds a private hook function to the input loop (currently only if readline library is used). The hook function is called every 1/100s and polls for events. Whenever events are pending, it executes the user defined callback associated with the event. In case where the event check occured while Octave is already executing a callback, then depending of the interruptibility propriety of this running callback, the current event callback is called or not. If not, it will be discarded or kept for later handling, depending on the discardability propriety of the event.

Sending commands and receiving results

Octave interpreter can request the module to execute some module-specific commands. These commands depend on the implementation of the module. But independently on the module implementation, Octave stores the command type and its argument in a slot, then it notifies the module by writing in an anonymous socket, and then it blocks waiting for a response from this same socket. Meanwhile, the module receives the signal on its socket, retrieves the command type and its argument and executes it. The execution code depends on the module implementation. The commands are identified by a simple integer. The first few integers are not to be used by the module implementator, because they are used to do specific functions: enabling/disabling events and exiting the module. The user-types are to be handled by a specific function implemented by the module.

Events and callbacks

Events are currently identified by the triplet (module_name, object_name, event_name). To an event is associated a single callback. The callback can be defined by an expression to evaluate (currently buggy) or by a function handler. When enabled, the module receives an instance of cmo_event object that identifies the event and contains its callback. The module shall enable the event and shall send this same instance back to Octave whenever the event occurs. The module shall just stop sending events when the disable command is received. Octave events handling loop will poll for the events and will call the associated callback unless the interpreter is currently running a non-interruptible callback, in which case the event may be discarded or delayed.


The source code contains a test module tmod_module in the ./src/tests. It is a timer that, when enabled, sends periodically an event. Check the test_*.m examples for how to use it.


A Doxygen documentation with source is provided in the following package: cmo-0.0.1-doxygen.tar.gz. Untar and use any browser to read the index.html file therein.


After a proof of concept, CMO is evolving to a usable project. Current stage is debugging the code. Subsequent step is to provide an Octave GUI Module based on it. This may result in implementing a new Octave data type taylored for CMO and representing abstract objects.


A preliminary package useful only for developers is to be downloaded from this cmo-0.0.1.tar.gz, it is distributed under the GPL v2 or later licence.
Last modified: Mon Feb 2 07:32:29 CET 2004