Lazy g_main_loop()

[Kyryll A Mirnenko aka Mirya]

On Thursday 27 September 2007 13:20, I wrote:
> Back to this thread:
> I've rebuilt glib20 with #define G_MAIN_POLL_DEBUG (gmain.c), it now
> outputs some data about polling, what I have from debug is:
>
> [my routine from another thread says it has just called g_idle_add_full()
> to add my callback ]
> [18 seconds of inactivity]
> g_main_poll(5) timeout: 18125 - elapsed 18.1255200000 seconds
> [my callback says it has just been entered]
>
> Maybe someone knows, why those 18 seconds were wasted.

  I finally got rid of this, maybe someone want to know the reason; it's all 
about intergration a multithreaded frontend to the single-threaded libpurrple 
(for those participating in the Skype plugin discussion it may be useful 
too).
  Suppose I want to send a message via libpurple from an alternative thread 
(not the one running glib mainloop), so I need to call g_idle_add_full() (or 
purple_timeout_add was offered for portability). Anyway, if main loop is in 
poll(2) call now, the callback won't be called till it exits it. It's not 
always what we need (the timeout may last up to ~30 sec), so after the 
callback is added g_main_context_wakeup() should be called to interrupt 
mainloop polling and process the event "just now".
  More, to make g_main_context_wakeup() work, g_thread_init() must be called 
on library initialization.
For me glib documentation describes it poorly, at least I had to dig the glib 
sources to find out those two functions should be called to make it all work.
-- 
Regards, Mirya
ICQ #313898202