Using select()/poll()

Hi,

For various reasons, I’m using a simple co-operative multitasking scheme
in my program whereby all I/O is done through a single multiplexer
that calls select() (or poll(), or whatever the win32 equivalent is).

I wonder if its possible to use SDL in such a setup – I’d need to be
able to grab the file descriptor(s) SDL reads from for input events, and
add those to the set of polled fd’s. Then if one of the SDL fd’s shows
available input, I will call SDL_PollEvent.

Any suggestions? I know its not portable, but portability is not the top
concern here – I can always have the same code implemented several
times for various platforms.

Slava

Hi,

For various reasons, I’m using a simple co-operative multitasking
scheme in my program whereby all I/O is done through a single
multiplexer that calls select() (or poll(), or whatever the win32
equivalent is).

I wonder if its possible to use SDL in such a setup

yep

– I’d need to be able to grab the file descriptor(s) SDL reads from
for input events,

nope

There are no file descriptors associated with any SDL events at all.

Keep in mind this doesn’t included extended SDL events, which are not
generated by SDL, but SDL is kind enough to let arbitrary events be put
into its event queue by other libraries. So if there’s a networking
library out there (maybe SDL_net already does this) written for use
with SDL, then it probably DOES have some file descriptor associated
with the source / cause of certain SDL events.

You’re barking up the wrong tree. The select() fuction (when not being
used as portable high-precision sleep, coughSDL_Delaycough) is for
use with I/O streams, be they files or sockets or devices or pipes or
any other kind of I/O stream there is.

Most (if not all) of the events represented by the SDL_Event are
generally generated by the system invoking SDL callback functions, or
by SDL rummaging an event queue, perhaps not dissimilar to its own.
This of course depends on the platform, and the SDL implementation
being used.

So far, just the facts. Now for my opinion.

It sounds to me like you want to unify the components of your program
responsible for I/O and event handling. Instead, why don’t you set up
I/O availability so that it throws a custom SDL event into the
SDL_Event queue?

To put it simply, instead of merging event handling into your I/O
handling, you’d be doing it the other way around.

On the other hand, maybe unity isn’t what you want at all, and you just
have a boner for unix’s style of I/O management. I can relate to this
feeling, in which case, again, you’re barking up the wrong tree.

I hope some other SDL mailing list members will confirm (one way or the
other) some of the possibilities I inconclusively mentioned (such as
whether or not SDL_net puts custom SDL events into the SDL event
queue.)

Good luck.On Nov 20, 2004, at 2:20 PM, Slava Pestov wrote:

Donny Viszneki wrote:

nope

There are no file descriptors associated with any SDL events at all.

Yes there are, for instance on X11 SDL ultimately reads events from the
X11 socket.

You’re barking up the wrong tree. The select() fuction (when not being
used as portable high-precision sleep, coughSDL_Delaycough) is for
use with I/O streams, be they files or sockets or devices or pipes or
any other kind of I/O stream there is.

I know what select() does.

Slava

Donny Viszneki wrote:

nope
There are no file descriptors associated with any SDL events at all.

Yes there are, for instance on X11 SDL ultimately reads events from
the X11 socket.

The fact that that particular implementation of SDL reads from a stream
is irrelevant.On Nov 20, 2004, at 3:52 PM, Slava Pestov wrote:

You’re barking up the wrong tree. The select() fuction (when not
being used as portable high-precision sleep, coughSDL_Delaycough)
is for use with I/O streams, be they files or sockets or devices or
pipes or any other kind of I/O stream there is.

I know what select() does.

Slava


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hi,

For various reasons, I’m using a simple co-operative multitasking scheme
in my program whereby all I/O is done through a single multiplexer
that calls select() (or poll(), or whatever the win32 equivalent is).

I wonder if its possible to use SDL in such a setup – I’d need to be
able to grab the file descriptor(s) SDL reads from for input events, and
add those to the set of polled fd’s. Then if one of the SDL fd’s shows
available input, I will call SDL_PollEvent.

Any suggestions? I know its not portable, but portability is not the top
concern here – I can always have the same code implemented several
times for various platforms.

Use the source, Luke. Take a look down inside of the Linux source code
for SDL in src/video/x11/SDL_x11events.c and you will find a select()
call. That is to say, SDL already does what you want for handling input
devices. Don’t stand the world on its head, use the structure that is
already there. It is not so hard to build a separate thread the checks
other fds and generates SDL input events. Take a look at the net2
project at http://gameprogrammer.com/programming.html to see how to do
that for networking. The same principle can be applied to all input.

	Bob Pendleton

	Bob PendletonOn Sat, 2004-11-20 at 13:20, Slava Pestov wrote:

Slava


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

Donny Viszneki wrote:

The fact that that particular implementation of SDL reads from a stream
is irrelevant.

Its relevant to what I’m doing, in particular I’m not adverse to
platform-specific code.

Slava

Hi,

For various reasons, I’m using a simple co-operative multitasking
scheme in my program whereby all I/O is done through a single
multiplexer that calls select() (or poll(), or whatever the win32
equivalent is).

I wonder if its possible to use SDL in such a setup

yep

– I’d need to be able to grab the file descriptor(s) SDL reads from
for input events,

nope

There are no file descriptors associated with any SDL events at all.

Keep in mind this doesn’t included extended SDL events, which are not
generated by SDL, but SDL is kind enough to let arbitrary events be put
into its event queue by other libraries. So if there’s a networking
library out there (maybe SDL_net already does this) written for use
with SDL, then it probably DOES have some file descriptor associated
with the source / cause of certain SDL events.

You’re barking up the wrong tree. The select() fuction (when not being
used as portable high-precision sleep, coughSDL_Delaycough) is for
use with I/O streams, be they files or sockets or devices or pipes or
any other kind of I/O stream there is.

Most (if not all) of the events represented by the SDL_Event are
generally generated by the system invoking SDL callback functions, or
by SDL rummaging an event queue, perhaps not dissimilar to its own.
This of course depends on the platform, and the SDL implementation
being used.

So far, just the facts. Now for my opinion.

It sounds to me like you want to unify the components of your program
responsible for I/O and event handling. Instead, why don’t you set up
I/O availability so that it throws a custom SDL event into the
SDL_Event queue?

To put it simply, instead of merging event handling into your I/O
handling, you’d be doing it the other way around.

On the other hand, maybe unity isn’t what you want at all, and you just
have a boner for unix’s style of I/O management. I can relate to this
feeling, in which case, again, you’re barking up the wrong tree.

I hope some other SDL mailing list members will confirm (one way or the
other) some of the possibilities I inconclusively mentioned (such as
whether or not SDL_net puts custom SDL events into the SDL event
queue.)

SDL_net does not put events in the event queue. My library, NET2, which
is entirely based on SDL and SDL_net does do that. Well almost, I got
tired of the way the SDL event queue loses events so I implement my own
event queue system on top of SDL. It depends on all the SDL event queue
infrastructure, but, it doesn’t lose network events.

		Bob PendletonOn Sat, 2004-11-20 at 14:44, Donny Viszneki wrote:

On Nov 20, 2004, at 2:20 PM, Slava Pestov wrote:

Good luck.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

SDL_net does not put events in the event queue. My library, NET2, which
is entirely based on SDL and SDL_net does do that. Well almost, I got
tired of the way the SDL event queue loses events so I implement my own
event queue system on top of SDL. It depends on all the SDL event queue
infrastructure, but, it doesn’t lose network events.

SDL loses events in the event queue?! Could you explain this for me?On Nov 20, 2004, at 4:11 PM, Bob Pendleton wrote:

Donny Viszneki wrote:

nope

There are no file descriptors associated with any SDL events at all.

Yes there are, for instance on X11 SDL ultimately reads events from the
X11 socket.

You are, of course, both correct. There are no fds in any SDL event. On
many/most operating systems events are not delivered via anything even
vaguely related to an fd. So, it is correct to say that there is no
relationship between fds and SDL events. It is also correct to say that
on the UNIX like operating systems SDL has to use fds to get device
input.

You’re barking up the wrong tree. The select() fuction (when not being
used as portable high-precision sleep, coughSDL_Delaycough) is for
use with I/O streams, be they files or sockets or devices or pipes or
any other kind of I/O stream there is.

I know what select() does.

Calm down, you asked for advice and Donny gave you very good advice. The
fact that you don’t like what you are hearing is no reason to snap at
people.

	Bob PendletonOn Sat, 2004-11-20 at 14:52, Slava Pestov wrote:

Slava


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

I’ll probably just switch over to X11 for this.

Slava

Bob Pendleton wrote:> Use the source, Luke. Take a look down inside of the Linux source code

for SDL in src/video/x11/SDL_x11events.c and you will find a select()
call. That is to say, SDL already does what you want for handling input
devices. Don’t stand the world on its head, use the structure that is
already there. It is not so hard to build a separate thread the checks
other fds and generates SDL input events. Take a look at the net2
project at http://gameprogrammer.com/programming.html to see how to do
that for networking. The same principle can be applied to all input.

SDL_net does not put events in the event queue. My library, NET2, which
is entirely based on SDL and SDL_net does do that. Well almost, I got
tired of the way the SDL event queue loses events so I implement my own
event queue system on top of SDL. It depends on all the SDL event queue
infrastructure, but, it doesn’t lose network events.

SDL loses events in the event queue?! Could you explain this for me?

SDL has a fixed size queue and no way to force the application to read
from it. When the queue fills up, SDL dumps the events on the ground.
You can read all about the problem, the tests I did to confirm it, and
the library I wrote to get around the problem at:
http://gameprogrammer.com/fastevents/fastevents1.html

BTW, this is rarely a problem when handling input, but it is a serious
problem when using the event queue as a general interprocess
communication mechanism.

	Bob PendletonOn Sat, 2004-11-20 at 15:18, Donny Viszneki wrote:

On Nov 20, 2004, at 4:11 PM, Bob Pendleton wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+

Just curious. It sounds like SDL is broken. How come you went with a
separate library instead of submitting a patch?

ChrisOn Sat, 20 Nov 2004 15:38:43 -0600, Bob Pendleton wrote:

SDL has a fixed size queue and no way to force the application to read
from it. When the queue fills up, SDL dumps the events on the ground.
You can read all about the problem, the tests I did to confirm it, and
the library I wrote to get around the problem at:
http://gameprogrammer.com/fastevents/fastevents1.html


Chris Nystrom
http://www.newio.org/~ccn
AIM: nystromchris

SDL has a fixed size queue and no way to force the application to read
from it. When the queue fills up, SDL dumps the events on the ground.
You can read all about the problem, the tests I did to confirm it, and
the library I wrote to get around the problem at:
http://gameprogrammer.com/fastevents/fastevents1.html

Just curious. It sounds like SDL is broken. How come you went with a
separate library instead of submitting a patch?

SDL is not so much “broken” as faced with a problem that can’t be easily
solved on all platforms. The only way to fix it that I know of is to
ensure that SDL_PushEvent() waits for the queue to empty out before it
pushes anything new on the queue. That requires that SDL_PushEvent be
running in a different thread than the main thread when it is called, or
else a wait would prevent the reading thread from ever being able to
empty the queue and you would have a deadlock.

But, you can’t ensure that SDL_PushEvent runs in a different thread than
the one that is using SDL_PollEvent or SDL_WaitEvent. You can’t even
ensure that the platform you are running SDL on supports multiple
threads. The problem is very deep in the concept of building a game
library that runs on as many different platforms as SDL runs on. And,
the problem rarely, if ever, affects games.

NET2 is thread based and therefore can not be used on all the platforms
that SDL runs on. The problem is only serious in programs that use NET2.
So, it makes more sense to write my own library and not patch SDL.

Having said all that, I have talked recently with Sam about trying to
fix the problem on threaded platforms. He hasn’t ruled out fixing it.
OTOH, to fix it someone has to come up with a way to prevent deadlocks
when SDL_PushEvent is called from the event reading thread when the
queue is full. Changing the way the queue is stored so that the size can
be extended sounds like the best approach to me, but the effects of
changing the queue representation can be far reaching and have
unexpected effects on performance. It is more complicated than that
because you should only increase the size of the queue when you need to
avoid causing a deadlock. You never know what piece of code lurking in
the machine specific bits of SDL have dependencies on the queue
representation or the queue size.

SDL is NOT broken. It is showing the effects of being written by
people who are not omniscient and it is showing the effects of being so
successful that people, including me, are now trying to use it for
applications, like network servers, that it was never designed for. It
is far from being broken. And while it is not perfect, it is so much
closer to being perfect than anything else out there that it is worth
our time to make it more perfect.

We also have to remember that the value of SDL comes from its
simplicity. Each new feature must be consider very carefully. And,
anything that changes the semantics of SDL affects many people and
applications.

	Bob PendletonOn Sat, 2004-11-20 at 22:34, Chris Nystrom wrote:

On Sat, 20 Nov 2004 15:38:43 -0600, Bob Pendleton <@Bob_Pendleton> wrote:

Chris

±-------------------------------------+

SDL is NOT broken. It is showing the effects of being written by
people who are not omniscient and it is showing the effects of being so
successful that people, including me, are now trying to use it for
applications, like network servers, that it was never designed for. It
is far from being broken. And while it is not perfect, it is so much
closer to being perfect than anything else out there that it is worth
our time to make it more perfect.

Well said! You should place it somewhere on SDL’s main site and treat it as SDL’s motto :wink:

Ah yes, sorry for spam.

Koshmaar

Bob Pendleton wrote:

SDL is NOT broken. It is showing the effects of being written by
people who are not omniscient and it is showing the effects of being so
successful that people, including me, are now trying to use it for
applications, like network servers, that it was never designed for. It
is far from being broken. And while it is not perfect, it is so much
closer to being perfect than anything else out there that it is worth
our time to make it more perfect.

So, how about refactoring SDL’s event handling into a generic and
scalable ‘libevent’; then your I/O engine, as well as SDL proper, can
post events through this library, and client code can handle them in a
reliable manner. This is somewhat far-fetched, but I wonder if the SDL
developers are interested in persuing this direction.

Slava

Bob Pendleton wrote:

SDL is NOT broken. It is showing the effects of being written by
people who are not omniscient and it is showing the effects of being so
successful that people, including me, are now trying to use it for
applications, like network servers, that it was never designed for. It
is far from being broken. And while it is not perfect, it is so much
closer to being perfect than anything else out there that it is worth
our time to make it more perfect.

So, how about refactoring SDL’s event handling into a generic and
scalable ‘libevent’; then your I/O engine, as well as SDL proper, can
post events through this library, and client code can handle them in a
reliable manner. This is somewhat far-fetched, but I wonder if the SDL
developers are interested in persuing this direction.

As much as it possible, SDL event handling is already factored out into
separate files. But, I said as much as is possible. It isn’t necessarily
possible to factor it anymore than it is. Event processing is tightly
coupled to video on several platforms. Event handling can be done in a
separate thread on some platforms and not on others. A “libEvent” would
face the same portability problems.

In other words, if there is a reasonable solution to the problem it can
be applied to the existing SDL code base without refactoring SDL.

People, before you suggest refactoring SDL you should take a look at the
SDL source code.

	Bob PendletonOn Sun, 2004-11-21 at 17:56, Slava Pestov wrote:

Slava


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

±-------------------------------------+