[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Interrupting lua execution
- From: "rodhydeuk" <rodhydeuk@...>
- Date: Mon, 11 Nov 2002 08:35:47 -0000
I had a similar problem in that I had a bunch of lua contexts running
in separate threads, synchronized with a master thread. Each lua
context was only allowed to run for a short time before synchronizing
with the master thread, partly because there was rendering
involved, but mainly because I wanted to ensure that no one state
could hog resources. The solution had 3 aspects.
a) use pthreads (ok, I'm mostly developing on Windows XP/2000, but I
want portability and there are a few pthread libraries out there for
Windows) and a synchronize function, called by every thread including
in my case, the master thread.
b) use a count hook which is called every n instructions. I
retrofitted one onto lua 4.01 but I think there's one as standard in
5.0alpha. The hook callback calls the synchronize function.
c) ensure that some of the C/C++ functions called from Lua also
invoke the synchronize function.
All my tests worked (once I got over the deadlocks). I'm not
convinced that I needed threads to do this: in Windows I suspect that
fibers would have done the trick.
--- Rod
--- In lua-l@y..., "Chris" <jlsfjs@y...> wrote:
> Hello,
>
> after the VERY usefull help from Björn De Meyer I'm really
considering lua
> as a first choice for my (small and parttime) game project...
> Six months ago I've done some tests with a skeleton application
just to wrap
> and handle C++ <--> lua calls and that was fine.
>
> But, now I'm facing another problem. My first idea was (as in this
skeleton
> app) to attach a script context to every instance of a class that
would need
> it.
> For example :
> CWorld (1 instance)
> CScene (few instances)
> CCharacter (several instances)
> CItems (many instances)
> CSectors (several)
>
> Each C++ instance run its own lua context. This is very easy to do
and very
> clean to code. But unfortunately I have now a main render loop that
can't
> wait for a script to spend too long in its bytecode run. I can
control which
> instance is eligible to call lua (or maybe next time if we allready
spent
> too long in the instances loop)
>
> How could I do to interrupt a vm and switch it back later to
continue
> execution ? Is the debugger hook the one and only solution ? Is the
overall
> idea ok ?
>
> Thank you
>
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
> Yahoo! Mail : http://fr.mail.yahoo.com