A word of caution

SDL Development
1

multi-threaded events under Linux libc 5 can cause X11 to abort because
errno is not thread-safe. Also, under recent kernels, if an application
is looping very quickly, the event thread may starve and not get enough
CPU time to deliver events in a timely manner.

For these reasons, asynchronous events will be disabled by default in
future versions of SDL. If for some reason you still need them, you can
re-enable them by calling SDL_ThreadEvents(1) before calling SDL_Init()

Is there any situation where a program might want to do CPU intensive
tasks and handle events asynchronously?
I may remove asynchronous events altogether if there is no need for them.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

2

Is there any situation where a program might want to do CPU intensive
tasks and handle events asynchronously?
I would have thought that the MacOS solution was the simplest, just make
the main thread the event thread - if you want to do something big, make
your own thread!

njhOn Wed, 29 Apr 1998, Sam Lantinga wrote:

3

Is there any situation where a program might want to do CPU intensive
tasks and handle events asynchronously?
I would have thought that the MacOS solution was the simplest, just make
the main thread the event thread - if you want to do something big, make
your own thread!

This solution may sound elegant Nathan, but it usually makes things worse:
This means there’s no elegant way of feeding events to the worker
threads… you’ll need synchronization & thus add unnecessary overhead. In
the end you might end up with something like OpenSTEP (ie. the display
server and the app-kit are not thread-safe there).

We should rather decide what we what: Do we really need async events? If
not, how can we simplify the mechanisms & what are the drawbacks. If Sam
takes the async events out now, there’s probably be no way back, as future
code may depend on certain behaviour.

I personally don’t consider async events necessary in SDL, as the type of
application (primarily games) usually process all their events centrally.

cheers.
–phil.On Thu, 30 Apr 1998 njh at cs.monash.edu.au wrote:

On Wed, 29 Apr 1998, Sam Lantinga wrote:

4

I would have thought that the MacOS solution was the simplest, just make
the main thread the event thread - if you want to do something big, make
your own thread!

I tried that. It broke in way too many places.
Here are some very good thread guidelines from the Vinnie:Date: Tue, 28 Apr 1998 10:46:44 -0400
From: vfalco@mindspring.com (Vinnie Falco)
Subject: Re: Timers & Threads again…

  • Don’t use the multithread version of the C runtime library.

  • Don’t call standard C functions in the thread proc

  • Don’t do floating point conversions in the thread proc

He’s absolutely right. There are a couple of places where SDL event code
does ugly and potentialy dangerous things. X11 in particular is very
sensitive to being multi-threaded. It would be much safer and a bit faster
to move the event handling code into the main thread.

HOWEVER… this means that we would lose the functionality that I
developed async events for in the first place: The ability to chew
along blissfully, while other events are being handled transparently.

Unfortunately, as was made sadly apparent in the stars demo, you can’t
guarantee that an event thread will be serviced often enough, while if
you explicitly poll or wait for them, you’ll always get events when you
need them.

sigh Great idea, impractical for non-realtime OSs, I think.

Besides, it’s not really safe to do anything beside filter and change
the state of global variables from within event handlers anyway.

This solution may sound elegant Nathan, but it usually makes things worse:
This means there’s no elegant way of feeding events to the worker
threads… you’ll need synchronization & thus add unnecessary overhead. In
the end you might end up with something like OpenSTEP (ie. the display
server and the app-kit are not thread-safe there).

Yep.

We should rather decide what we what: Do we really need async events? If
not, how can we simplify the mechanisms & what are the drawbacks. If Sam
takes the async events out now, there’s probably be no way back, as future
code may depend on certain behaviour.

Yep.

I personally don’t consider async events necessary in SDL, as the type of
application (primarily games) usually process all their events centrally.

One vote.

What do you others think? This is a very important design decision here.

See ya!
-Sam Lantinga (slouken at devolution.com)

–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

5

I personally don’t consider async events necessary in SDL, as the type of
application (primarily games) usually process all their events centrally.

One vote.

What do you others think? This is a very important design decision here.

Yep, KISS applies here!

one vote!

njhOn Wed, 29 Apr 1998, Sam Lantinga wrote:

6

I personally don’t consider async events necessary in SDL, as the
type of application (primarily games) usually process all their
aevents centrally.

One vote.

What do you others think? This is a very important design decision here.

I would agree, so that makes it two votes. In my (limited)
experience, games can do fine with just a single thread, doing both
event handling and “game-running”.

/Emil

7

What do you others think? This is a very important design decision here.
Multi-threading is important in modern gaming, you definitely
want to be able to thread off sound from graphics and computations.
As we’re entering the era of multiprocessor home computers…

I say, ‘Yay’ to it.

Best Regards,
David

8

I would agree, so that makes it two votes. In my (limited)
experience, games can do fine with just a single thread, doing both
event handling and “game-running”.

Just to defend myself, may I point out that my original post was to have a
single thread(and only spawn off another thread if the programmer wanted
to… Anyhow, yep - Of course the bestest solution of all would be to
have interupts…

njhOn Thu, 30 Apr 1998, Emil Brink wrote:

9

What do you others think? This is a very important design decision here.
Multi-threading is important in modern gaming, you definitely
want to be able to thread off sound from graphics and computations.

Bring on the RTkernel!

njh
p.s. as for multiprocessor machines, they won’t be economical until moores
law fails, me thinks. I have 3 multiprocessor machines, and their price
performance has never really competed.On Thu, 30 Apr 1998, David Sowsy wrote:

10

p.s. as for multiprocessor machines, they won’t be economical until moores
law fails, me thinks.

I have 3 multiprocessor machines, and their price
performance has never really competed.

The problem there is not the performance of your machine. The problem
is the lack of skills of the majority of programmers out there to
exploit multiprocessor support in their applications. Binaries
that do support multiprocessor systems generally don’t perform well
on uniprocessor systems and the downfall is that the L.C.D. of all
computers is to have one processor. The proper use of threading
not only helps organize your code and data into distinct parts,
but also gains you performance for calculations.

Best Regards,
David Sowsy

11

What do you others think? This is a very important design decision here.
Multi-threading is important in modern gaming, you definitely
want to be able to thread off sound from graphics and computations.
As we’re entering the era of multiprocessor home computers…

This wouldn’t prevent multi-threading in your game, it would just
mean that you would have to check events periodically instead of
them arriving asynchronously.

Because of the way X11 is designed tho. you’d have to check events
in the same thread that does graphics.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

12

Just to defend myself, may I point out that my original post was to have a
single thread(and only spawn off another thread if the programmer wanted
to…

Right, although that other thread couldn’t handle events – it would handle
game AI perhaps.

Anyhow, yep - Of course the bestest solution of all would be to
have interupts…

That would be possible but you couldn’t service them in the interrupt
routine. You’d have to set a global flag that tells the rest of your
program that there might be input waiting.

(You couldn’t guarantee that there’s input waiting though, because of
the way you can check for input under X11 and the filtering mechanims)

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/