On 3/12/07, Peter Seibel <[EMAIL PROTECTED]> wrote: > Justin Heyes-Jones wrote: > Mmmm, spinning is bad, I have other uses for my CPU. ;-) Or I > misunderstand your suggestion. I know there's a patch floating around to > allow user events to be put on the SDL queue. Is that the right > solution? (As I understand it at the moment, my problem is that I want > my SDL window to be responsive to two sets of events--one generated by > SDL (mouse, video-expose, etc.) and the other generated by my Lisp code. > Ideally I'd like the thread handling the SDL window to block (rather > than polling) but obviously I can't block on two queues at once. However > I could--just thinking out loud here--use an extra thread to process the > the SDL events and put them on a Lisp queue which my app can also use > to inject its own events. > > Maybe my question is this: what's the threading model of SDL (or > lispbuilder-sdl)? Can multiple threads be calling sdl methods at the > same time? Or do I want a single thread managing the SDL window?
I wouldn't worry to much about CPU. If you run some of the examples (sdl-examples:setup-and-draw) this has the update frame rate set to 30fps, and takes less than 1% of CPU on my machine. And I don't think you need to worry about threading much either. If you call some update function from the :idle event handler you can put all your board game logic in there. SDL has threads, but I think we'd have trouble using them in a lisp process, I may be wrong. I didn't have much look creating a lisp function to act as a callback for SDL mixer library, which is similar to what you would need to do. So you should probably use the process/thread model in your lisp, or try to put all your application logic in the idle update call. Justin _______________________________________________ application-builder mailing list [email protected] http://www.lispniks.com/mailman/listinfo/application-builder
