[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Interrupting lua execution
- From: "Chris" <jlsfjs@...>
- Date: Mon, 11 Nov 2002 13:14:37 +0100
I think this could be a good solution... In fact it's ONLY a lua problem.
I think I will keep the render loop in the main thread of the application.
So, what is is job ?
Recursing down on the parent/child objects
Compute some weird stuff (inviewfrustum and so on)
Call the render methods for any object eligible to render
In fact, really specialised task that does not involve updating nothing to
the objects themselves.
So, I need a kind of EventManager class which could provide (amonst other
things) an idle method.
The idle method recurses also in the tree to achieve lua switching contexts
and execution of bytecode.
The lua calls would run in the same thread as the EventManager and NEVER two
lua calls would occurs at the same time.
So, all the stuff of the EventManager itself (lua related code and non lua
related code) would not produce slow down in the main app as they not run in
the same thread.
But, as my knowledge on thread is really weak, I just wonder if some C++
object instance method can be called by another thread and I wonder what
would happen in this scenario :
- EvenManager.idle() run a loop and descent the object tree (object
concerned by update of their state, so once again lua or not lua) as fast as
it can calling update() method for each object. This update method does many
things (eg computing the next position for a moving object) AND running lua
code (no matter the time it takes to return)
- The mainloop of the app does the same (I mean descending the tree) but for
rendering (calling draw() for each object instead of calling update) .
draw() method never affect the state of an objet, just compute with read
only data members (the inviewfrustum for example)
So I wonder if another thread (eventmanager) can safely call the methods of
an object running in a seperate thread (the main app thread)
Yes, I know that in that case the update method of an object can freeze the
update process for several time but depending on the kind of game (for me an
adventure game) is that so vital to have a CCharacter responding few
milliseconds later (issuing a move, starting to talk, ...) ???
Only the main character (third person game) would be controlled by the main
thread with a lua context running by its own.
Ahem... Don't sure to be clear (may be a small test app could be usefull)
Date: Mon, 11 Nov 2002 08:35:47 -0000
From: "rodhydeuk" <email@example.com>
Subject: Re: Interrupting lua execution
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.
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com