After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 525192 - 100% CPU if run main loop with no IO sources
100% CPU if run main loop with no IO sources
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: win32
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-win32 maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-30 21:37 UTC by Neil Roberts
Modified: 2008-03-31 18:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix (678 bytes, patch)
2008-03-30 21:38 UTC, Neil Roberts
none Details | Review

Description Neil Roberts 2008-03-30 21:37:28 UTC
Please describe the problem:
Under Windows, if you run a main loop without watching a file handle or the fake Windows messages file handle (so you just want to wait on a timeout) then it will take up a 100% CPU instead of waiting for the timeout.

Steps to reproduce:
This is noticeable in the Clutter SDL port on Windows.


Actual results:
The program functions normally but eats up 100% CPU

Expected results:


Does this happen every time?
Yes

Other information:
Comment 1 Neil Roberts 2008-03-30 21:38:57 UTC
Created attachment 108290 [details] [review]
Patch to fix

This patch fixes the problem by calling Sleep in g_poll if there are no I/O handles to watch but a timeout is given.
Comment 2 Tor Lillqvist 2008-03-31 07:47:11 UTC
Thanks. Patch committed to glib-2-16 and trunk:

2008-03-31  Tor Lillqvist  <tml@novell.com>

	Bug 525192 - 100% CPU if run main loop with no IO sources

	* glib/gmain.c (g_poll) [Win32]: Patch by Neil Roberts.
Comment 3 John Ehresman 2008-03-31 16:44:57 UTC
Shouldn't SleepEx be used to put the thread into an alertable wait state?
Comment 4 Tor Lillqvist 2008-03-31 18:16:46 UTC
Good point, fixed. Thanks.

Should the call to Sleep() in g_usleep() be changed to SleepEx(), too? Hard to say. I would say the logical answer would be yes, although code that cares for these things, or even uses User APCs, probably makes sure never to call g_usleep() anyway. I.e. put the SleepEx() in a loop, if it returns WAIT_IO_COMPLETION then re-sleep for the remaining time.
Comment 5 John Ehresman 2008-03-31 18:34:43 UTC
(In reply to comment #4)
> Should the call to Sleep() in g_usleep() be changed to SleepEx(), too? 

I don't have a good sense of whether it should be yes or no.  My sense is that adding it to g_usleep would make where APC's can be called less predictable.  OTOH, I've think that the select call will allow APC's to run.

Either way, it should be documented.