Justin Heyes-Jones wrote: > On 3/12/07, Peter Seibel <[EMAIL PROTECTED]> wrote: >> Frank Buss wrote: >> >>> It depends on your applications, but maybe it is better to use an >>> event loop and a second thread for a computer player or network >>> connection, because otherwise it is difficult to poll the events for >>> playing with the mouse.
>> Okay, so suppose I do fire up the window in a separate thread and use >> with-events to track events. What's the best way to modify the board >> from another thread--i.e. when I figure out that I want to add a stone >> to the board I need somehow to inject an event right, to tell the >> draw-board function to update things. > I would just let the main thread or loop spin, drawing a list of > objects. Then when you want to draw something, add it to the object > list. 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? -Peter -- Peter Seibel : [EMAIL PROTECTED] Gigamonkeys Consulting : http://www.gigamonkeys.com/ _______________________________________________ application-builder mailing list [email protected] http://www.lispniks.com/mailman/listinfo/application-builder
