The Benefits of the GREIO "queue" Option

Daniel Gonzalez

September 12, 2022 20:32

In order to discuss what the -ogreio,queue option does, we first have to look at the default event processing behavior.

Conceptually, there are two “queues”, one is the GREIO channel and the other is an internal event queue inside the engine.

Incoming events from a backend will be written to the GREIO queue, then the GREIO plugin will read these events into the internal queue.

By default, when an event is received, the GREIO thread is blocked until the main thread has finished processing the event. Only once it has been processed will the plugin read further events from the GREIO queue. This means at most there will only ever be 1 GREIO event in the internal queue.

This also means that the screen will be redrawn once per GREIO event that changes data.

The -ogreio,queue option however, does not block the GREIO thread. This option changes the plugin's behavior so that it will insert events into the internal queue without waiting for the previous one to complete being processed.

This means that with queue the screen can be redrawn for any GREIO event received before the first event that changes data.

Since you can squeeze multiple events into the queue, this essentially enables a type of batch processing.

This can easily be demonstrated if we take the ClusterIO sample and use the IOConnector's sliders to simulate a large influx of events.

This is the default behavior, without queue:

You can see that there comes a point where the events are coming in faster than the app can "keep up" with, and the app is still processing the events for some time after the slider has stopped moving.

With queue enabled:

You can clearly see that with the queue option enabled, because the GREIO thread is not blocked the application is able to "keep up".

Comments

1 comment

Official comment

Garry Clarkson
May 08, 2026 12:24 (Edited May 08, 2026 12:25)
There have been some recent enhancements to the Storyboard IO in relation to the queue option described above.

It is now possible, from Storyboard release 8.2.1 onwards, to further control the queue behaviour for asynchronous events being posted to the Storyboard engine through the Storyboard IO plugin and API.

This new feature can still finding that their back-end application still triggers a queue full response when sending higher volumes of events to the front-end before the maximum number of events are pushed to the queue.

The new option to configure the greio plugin with queue_max is done at engine start-up and is considered a static 'system' setting option that will apply from start-up e.g: within a simulator or command line option:
```
-ogreio,channel=my_queue,queue,queue_max=256
```
On an MCU platform the options are passed as part of the arguments array:
```
args[n++] = "greio";
args[n++] = "channel=my_queue,queue,queue_max=256";
```
The updated queue configuration mechanism has also been extended to the GREIO API which now allows you to set (and override) the max queue size programmatically at the point when a channel is opened using the GRE_IO_FLAG_MAX_QUEUE flag passed to gre_io_open().

This would allow you to potentially change behaviour at runtime though some configuration screen or somesuch...

From greio.h:
```
/**
 * Open an IO connection using a named connection.
 * 
 * Some implementations may support GRE_IO_FLAG_MAX_QUEUE flag when opening a channel for reading.  
 * With the GRE_IO_FLAG_MAX_QUEUE flag included, the maximum queue size can be specified as the first variable argument.
 * If the flag is not set or if the implementation does not support it, then the queue size will be determined by the implementation.
 *
 * @param io_name The name of the io-channel to use
 * @param flag The mode you want to open the queue in
 * @return handle to greio channel or NULL on failure.
 */
GREIO_SHARED_EXPORT gre_io_t *gre_io_open(const char *io_name, int flag, ...);
```

Please sign in to leave a comment.

Didn't find what you were looking for?

New post