[SDL] SDL events and threads on Win32

[skaller]

On Fri, 2006-02-10 at 17:34 +0200, Vassilis Virvilis wrote:

> I haven't heard about felix. Looks nice...

:)

> > spawn_fthread { drawchan (clicks, the Drawing); };
> > spawn_fthread { framerate (clicks, 0.1); };
> > spawn_fthread { execute (rotation, the rotate); };
> > spawn_fthread { framerate (rotation, 0.1); };
> 
> Some how threads are scheduled when (block until) their
> argument changes? (keyboard, active, resize, clicks, rotation)?

Its the same as reading and writing files. The channels are
clicks and rotation in the above. The fthreads don't have names
in this example: { ... } is an anonymous procedure.

> > There is no loop here!
> 
> Yes there is! You are just hiding it very well :-)

There's no loop in the Felix code above. There are loops in the
C++ code that schedules the fthreads. There are also loops
in your favourite Operating System doing the same thing.

> > Sure .. there is a loop .. but
> > it blocks READING the event!

> That's the right thing to do.

I think so too ..:) 

However I'd like to *prove* it, which is best done
by simply writing demo programs and letting people make
up their own minds.

however there is a simple fact which is a killer argument :)
Algorithmic code can implement callbacks trivially by simply doing

	loop: 
		event = read(); 
		callback(event);
		goto loop;

Therefore, reading events is superior to callbacks
because it subsumes callbacks as shown.

> I still believe that you have to take a look at fastevents by
> Bob Pendleton to see how to implement a non polling
> loop for SDL events

I have. However I think his main concern was reading sockets.
We have our own high performance socket handling stuff,
using epoll (linux) kqueue (BSD, OSX), and io completion 
ports (Windows). On linux we may even go down to 
direct kernel calls with the new io stuff in 2.6 kernels.

The interest in SDL is for gaining access to multi-media
devices -- video, audio, mouse, joystick -- with a portable
interface.

> Hmm... looks like the approach of fastevents. I am not sure.
> However I think it's not possible to block indefinitely wait
> user input (event) 

My code didn't. The trick is to make reading events
and doing graphics mutually exclusive, in case the underlying
system isn't thread safe. So there is a mutex to establish
the exclusions. The only problem then is that SDL_WaitEvents
may be blocked, so we simply call SDL_PostEvent with a dummy event
which unblocks it.

This is much better than polling. Or rather,
it would be if it worked :) It works on Linux,
because Xlib doesn't care which thread reads
the event queue: AFAIK SDL actually runs its event
loop in a thread? On Windows it doesn't, because
Windows has an event queue for every thread.

> In order to implement timers you are possibly have also
> your own queue on top of the SDL queue.

We don't use SDL for timers. Felix is a general purpose
programming language. We provide timers and sockets using
the best possible underlying OS techniques, then hide all
that in an abstraction layer. SDL is for multi-media:
we don't want to force people writing web servers
(for example) to use SDL. Thus, we don't use SDL timers,
threads, or sockets, since we have our own, with interfaces
specifically designed to integrate with the synchronous
fthread things.

>  I think that the
> problem is you have to wake up once in a while in order to
> give the chance to the lower levels to fill up their queues...

Yes indeed. That's why a thread is good, because it reads the
events without the mainline needed to poll. The thread automatically
gets control when the mainline blocks, and possibly even while
it is running -- unless it is locked out by the mutex. However
unless you're saturating the CPU, drawing graphics has to leave
some time free, and, at a framerate of 20FPS+, it is unlikely the
user can fill up the OS event queue in one frame .. I certainly
can't type 20 chars per second, and I'm sure the OS can queue
more than 1 keyboard event at a time :)

Anyhow, I have done the busy/wait loop workaround, it works
on Linux, but an unrelated link problem is stopping me testing
it on Windows.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net