From: John L. <jla...@gm...> - 2009-05-17 21:04:34
|
On Sun, May 17, 2009 at 4:04 PM, John Labenski <jla...@gm...> wrote: > On Sun, May 17, 2009 at 2:47 PM, TOUPIN Youen <you...@wa...>wrote: > >> It seems the problem comes from the Connect function call, which uses >> the current lua state to register the event callback. When the callback >> is called, it is from that lua state, which, in my case, is the >> coroutine, not the main lua thread. Is there any reason for this >> behavior ? Wouldn't it be better to get the main lua thread (I think it >> can be retrieved from the coroutine) when the Connect function is >> called, and use it instead of the coroutine ? >> >> > I don't think your example makes sense. You create a coroutine that creates > a wxDialog then yield it and try to resume it from the yielded coroutine. > Shouldn't the wxDialog be created in the main thread which can control the > coroutine as appropriate? > > I should clarify, in Lua there is no way for a coroutine's code to be run when it's yielded, unless I'm missing something. You, with the wxWidget's event loop can "cheat", so to say, and pop back into the yielded coroutine to run code which would not normally be possible. I think it's a reasonable constraint that a coroutine cannot resume itself since 1) it stays truer to Lua's behavior, 2) doesn't require second guessing the user by swapping back to the main thread, which would be unexpected to say the least, 3) the fix is simple, put any code that will control a coroutine into the parent thread that created the coroutine where it belongs. Regards, John |