Re: sharing one lua_State between threads ?

[gary ng <garyng2000@...>]

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