lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hello mark,

Friday, December 22, 2006, 9:40:47 AM, you wrote:

mg> I am not a co-routine guy, still think like a C++ programmer, not a lua programmer.

mg> Well the concepts still stand: globals, or a window attribute.

mg> The question is more: how are you going to manage the lua-states yourself?
mg> If you have several states, then you have to know which one
mg> is for which. If you have a state whose task it is do the
mg> updating, you have to know which one to call. If you have another
mg> state which manages the keypresses or mouse clicks, you need to
mg> deal with that.

I have only one lua main state.

The problem is, coroutines have different lua states with lua main thread.
and I can't guarantee no one calls win32 api (with the extension
lib) from a coroutine. Many win32 api may call WinProc indirectly.

Storing the current lua state pointer everytime lua calls C is a good
idea as the lhf said.

Today, I found another way:
Creating a lua thread (use lua_newthread) at the beginning, and never
resume it. Everytime I should do something in the Winproc, I can
use this "dead thread"'s state pointer. It works well, because no one
can resume this "dead thread" explicitly, and I only "borrow" this
dead thread's stack to do something in lua.


-- 
Best regards,
 Cloud                            mailto:cloudwu@163.com
            http://blog.codingnow.com

[富贵而骄, 自遗其咎]