For long running data producers in UI framework, should this be done in the event loop?

Question

Consider Clutter and Enlightenment. They both provide idlers and adding event callbacks into the event loop. Neither one seems to advocate the use of threads but instead suggest event driven programming.

However, what if you have a data producer that chews up seconds of processing before returning?

Surely adding this sort of processing in the idlers or event loop will stop the UI being responsive?

How should you do these sort of things with UI frameworks?

FYI - We are using both these frameworks in Python.

Thanks.

Answer 1

if your producer code cannot be broken off into small chunks, then you should definitely use threads. Clutter, like and even more so than GTK+ given the threading model of GL (the context for the state machine is stored in thread local storage), cannot be used by different threads except the one that called clutter_init() and clutter_main(); it is, on the other hand, perfectly acceptable to use the GMainLoop facilities to schedule the UI update from a thread into the main loop.

Clutter has an example on how to achieve this pattern in the Git repository:

http://git.gnome.org/browse/clutter/tree/examples/threads.c

in short, with the blocking operation being executed inside a thread, you should schedule the UI update by using gobject.idle_add().