Hi,
I’m building a GTK 3 app with the main thread running the GTK main loop and another thread that does g_idle_add (foo, bar) and then g_idle_add (foo, baz). Is it safe to assume that the main loop will always call foo (bar) and foo (baz) in that order?
That’s what the current implementation would do IIRC but a) this is not documented and seems more like an implementation detail, and b) if you need to rely on this that probably means that your code should be refactored a it 
What’s the context where you would need this guarantee?
Thank you for the answer.
The app is an expect-like wrapper for a console program. I have a thread that reads the program’s stdout and hands it over to the main thread for parsing and rendering in the GUI. (I can’t / don’t want to use GIOChannel because I’m building this in Go where there are no bindings for it / I prefer to use Go’s own I/O facilities.) Currently I send each chunk of output like g_idle_add (process_chunk, chunk). I think I should refactor this so that the stdout-reading thread writes directly to the parser’s buffer (under a mutex) and then just informs the main thread that new data is available, like g_idle_add (process_buffer, NULL). This will also skip some unnecessary copying.
I don’t know how the Go bindings work, but it seems like what you’re actually looking for is a channel to send the data over as it gets ready instead of using g_idle_add() for each piece of data individually.
The Rust bindings at least provide integration for various channel types, something similar should be doable for Go too. And especially because in Go channels are a first-class language construct, I would expect there to exist some integration 
That basically re-implements some kind of channel, so yes something like that is how I would do it.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.