A word of caution

Sam Lantinga slouken at devolution.com
Wed Apr 29 15:57:44 PDT 1998


> > 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: "Vinnie Falco" <vfalco at mindspring.com>
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/
--



More information about the SDL mailing list