We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 982 - Remove polling from 1.3 event queue.
Summary: Remove polling from 1.3 event queue.
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 enhancement
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-14 00:12 UTC by Ryan C. Gordon
Modified: 2013-05-21 01:14 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan C. Gordon 2010-04-14 00:12:20 UTC 
I made an effort on this in 1.2 in a patch we never committed, since it was complicated and not 100% effective in some corner cases. That's Bug #323 for reference. The goal is to remove polling from the event queue (either block in the kernel indefinitely or block until an app-specified timeout) so that CPU time is reduced and battery time is increased.


Chatlog of the basic idea follows.

Ryan C. Gordon
Jabber
2:58
anyhow, if you really want to tackle something, we could use an API to make SDL block until something happens.
2:58
Rather, we have that.
2:58
But internally, remove all the polling.
Sam Lantinga
GTalk
2:59
The problem is that we have lots of different event sources.
Ryan C. Gordon
Jabber
2:59
So each subsystem returns an abstract handle thing, and then you can tell the platform to wait on this pile of abstract handles.
Sam Lantinga
GTalk
2:59
SDL_PushEvent() for one. :)
Ryan C. Gordon
Jabber
3:00
PushEvent() can make the queue stop waiting. We'll signal the waiting thread.
3:00
literally signal it.
Sam Lantinga
GTalk
3:00
mph
3:00
that would work
3:00
EINTR :)
Ryan C. Gordon
Jabber
3:00
precisely
3:01
But it would be good to be able to get the platform to know that on Windows, all these abstract handles can be passed to WaitForMultipleObjects(), and on Unix, they can go to select().
Sam Lantinga
GTalk
3:01
Can you enter a bugzilla bug for it?
Ryan C. Gordon
Jabber
3:01
yeah
Sam Lantinga
GTalk
3:01
I'll have to look at what we can do on other platforms like Mac OS X
Ryan C. Gordon
Jabber
3:01
yeah
3:02
There would probably need to be a way for a subsystem to say "I'm some fruity thing that can't block" either because it can't or because it's talking to some external API like esound that doesn't support it.
3:02
In that case: tough luck.
3:02
But for people with iPhones, you know all your subsystems can be made to work.
3:03
(insert your favorite battery-powered thing here.)
Sam Lantinga
GTalk
3:03
Mmm
Ryan C. Gordon
Jabber
3:04
esound was a bad example, since you don't wait for events from it.  :)
3:04
anyhow
3:04
Can I just paste this into the bugzilla? This rambling basically covers my thoughts.
Comment 1 Nathaniel J Fries 2011-01-07 14:13:23 UTC 
This seems largely impractical. Windows and XInput both require you to poll for events internally, anyway. 

How much do you think that polling over a non-polling system really costs?
Comment 2 Ryan C. Gordon 2011-01-07 16:21:27 UTC 
(In reply to comment #1)
> This seems largely impractical. Windows and XInput both require you to poll for
> events internally, anyway. 

That's not true.

> How much do you think that polling over a non-polling system really costs?

On desktops? Not much. On laptops: more than you'd like. On cell phones: a lot.

--ryan.
Comment 3 Sam Lantinga 2011-02-16 03:47:01 UTC 
Ryan, do you have this patch handy?  I'm hoping to do the mutex-free event queue soon and if you want to go for this, now's a good time.