[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: sharing one lua_State between threads ?
- From: Stefan Sandberg <keffo.sandberg@...>
- Date: Tue, 03 Jul 2007 13:30:31 +0200
Sure, luatask, lualanes etc.. Lots of stuff are available..
You can get away fairly cheap by just using a proxy-state for example..
As long as you know exactly where and when you access stuff, you'll be safe.
Still, lua was never intended to handle threading natively, it used
coroutines to solve parallel execution. (but there is a growing need for
true preemptive threading, multicore's are taking over)
gary ng wrote:
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
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
--- Stefan Sandberg <firstname.lastname@example.org> 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:
Is it a must to have lua_lock/unlock properly
if I have to share a single lua_State among
Park yourself in front of a world of choices in
alternative vehicles. Visit the Yahoo! Auto Green
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.