Dan Sugalski wrote:
chromatic wrote:SDL_WaitEvent,
> So for SDL, I'd start a separate thread that blocks onconsumer> creating and posting events when they happen. My main program would > handle the events as normal Parrot events. Standard producer> stuff. > > Since it's blocking, it won't eat up too many resources -- > that's nice. It'd be nice to have the SDL event thread ignore events
> I don't care about though, instead of creating event PMCs I'll just > throw away later.
You can always Get Horribly Clever in the event handling thread and look at what the SDL library's handed you. If it's uninteresting you can just throw it away rather than creating an event to be discarded.
> Is this what you have in mind?
Yep.
As I pointed out in another post, this doesn't work for integrating with at least two significant "event sources:" Windows and the Mac OS. :) UI events need to be handled synchronously on the thread to which they were delivered, since the GUI APIs are not threadsafe.
Oh, it's worse than that--GUI commands need to be issued from the main thread, at least with OS X. (There's no actual requirement as to which thread handles the actual events as long as you treat the OS event queue as the thread-unsafe thing it seems to be) Or so the docs seem to indicate, though they may be a bit conservative.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
