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().

Answer 2

There is actually a nicer way to achieve this without threads by using gobject.idle_add and a generator function:

def my_task(data):
    # ...some work...
    while heavy_work_needed:
        ...do heavy work here...
        progress_label.set_text(data) # here we update parts of UI
        # there's more work, return True
        yield True
    # no more work, return False
    yield False

def on_start_my_task_button_click(data):
    task = my_task(data)
    gobject.idle_add(task.next)

See this FAQ entry for details