Thanks.
That would mean that even I am not into sharing my
objects between threads(let's say each thread would
have its own ojbects to play together with shared
read), I would still need to define this two functions
or the VM state would be pretty bad. So the situation
is pretty much the same as in python's one big global
lock ?
I believe some kind of mutex, semaphore library is
needed if I really need inter-thread
communication(like sharing an object with multiple
write access in the VM).
Has anyone already done something like that ?
I tried to search around on google but failed to find
any reference for this usage scenario but
unfortunately is needed as I am writing a FUSE binding
which needs to be multi-threaded for maximum
performance.
--- Stefan Sandberg <keffo.sandberg@gmail.com> wrote:
Those macros makes sure the state internals are
safe, it doesn't mean
you can share a state without care.
It basically locks the state for each vm op, but the
language on it's
own doesn't have any constructs for thread safety,
deadlocks are pretty
much guaranteed to happen.
gary ng wrote:
Hi,
Is it a must to have lua_lock/unlock properly
defined
if I have to share a single lua_State among
threads ?
____________________________________________________________________________________
Park yourself in front of a world of choices in
alternative vehicles. Visit the Yahoo! Auto Green
Center.
http://autos.yahoo.com/green_center/
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html