Re: [PATCH] Proposal: asynchronous coroutines and multithreading

[mniip <14@...>]

> Per-state mutexes will be quite tricky to implement, as you don't really have
> per-state variables. You can have a reference to the same table in two
> coroutines. You can even have access to the same local numeric value from two or
> more coroutines if you pass a function around that have it as an upvalue.
> 
> One way to implement per-state mutexes is for every TValue to have an "owner"
> state, so you lock that state mutex before dealing with the value. This will
> probably require huge efforts and will increase size of TValue, which is not
> good (OK, on 64bit architectures, you can squeeze in 32bit index without size
> penalty as TValue is being padded to 16 bytes anyway, that is in Lua 5.2).

Yeah I'm rethinking it right now, they won't be per-state mutexes but per-object
mutexes. But you don't have to lock TValues at all! You only have to lock
GCObjects. The only case, I think, where 2 states may simultaneously access the
same TValue is tables, but at that point it's easier to just lock the whole
table (which is a GCObject by the way).

-- 
/* mniip */