On Nov 23, 2007 3:52 PM, Tor Lillqvist <tml@xxxxxx> wrote:
Totally agree :-)
I usually add a g_usleep() idle callback which also provide a heartbeat info
for my application. This way, at least the main loop is doing something :-)
The g_usleep() could be 5 sec, 10 sec ... don't matter. If it's long enough,
it won't hurt any performance.
KC
> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTRPlease don't unnecessarily use WinMain(), it only confuses matters,
> lpCmdLine, int nCmdShow)
and can make people think it is significant for the problem. (It
isn't)Well, you haven't added any event source to the main loop. What do you
> {
> GMainLoop *MainLoop = NULL;
>
> MainLoop = g_main_loop_new(NULL, TRUE);
> g_main_loop_run(MainLoop);
> }
> Even this minimalist program eats 100% CPU.
expect the code to do? Sure, on Windows GLib gets stuck in a loop and
on Linux it apparently just hangs forever instead, and it probably
could be argued that it should just hang forever on Windows, too, but
from a functionality perspective, what is the difference? In both
cases, the code will forever be doing nothing.
Totally agree :-)
I usually add a g_usleep() idle callback which also provide a heartbeat info
for my application. This way, at least the main loop is doing something :-)
The g_usleep() could be 5 sec, 10 sec ... don't matter. If it's long enough,
it won't hurt any performance.
KC
On Linux it will call poll(NULL, 0, -1) which hangs forever. I can't
see this behaviour documented in the poll(2) manpage, though. The
g_poll() function used in GLib on Windows to "emulate" poll() just
returns immediately if there is nothing to wait for. I guess it would
be easy to change that to make it hang forever instead. I can't say I
am convinced that would be more correct, though.
--tml
_______________________________________________
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
