Re: retrieve top-level lua_State?

[Graham Wakefield <lists@...>]

On Jun 6, 2009, at 12:28 PM, Peter Cawley wrote:

> On Sat, Jun 6, 2009 at 7:02 PM, Wesley Smith<wesley.hoke@gmail.com>  
> wrote:
> >
>
> I think that a lua_getmainthread function would be a good addition to
> the API, however this situation can be avoided.
>
> First, C code can detect if it was called from the main thread
> (lua_pushthread(L) will return 1). It could enforce a policy of being
> only called from the main thread, throwing an error if it wasn't.

Such a policy might not be acceptable.

> Alternatively, when creating userdata with callbacks, if it's not
> called from the main thread, then it should keep a reference to the
> thread which created the userdata in the userdata environment table,
> thus ensuring that the thread will not be collected before the
> userdata.

If the thread has an error, is it certain the userdata and thread be  
collected (including the __gc call on the userdata)? Would further  
processing on the thread work in the userdata __gc method?

> If I setup a callback from a thread, then I would expect
> callbacks to be made to that thread rather than the main thread, even
> though that prevents the thread from being collected.

This may not be the expectation in all cases.

I have a simple scheduler that spawns threads which can yield back to  
the scheduler. Canceling a thread is a simple matter of removing it  
from the internal table of threads, allowing it to be collected. If  
any userdata were created in the thread, they should be collected when  
the thread is canceled. If the userdata held references to the thread,  
then there would be no way to cancel the thread externally, which  
would break the intended semantics. Similarly, user code may create a  
global reference to such userdata in a higher-level state, also  
preventing the thread from ever being collected. It is desirable for  
the user to be able to make such global references, and expect  
callbacks from C into the global state (the only one guaranteed to  
persist), even if the userdata was created in a temporary sub-thread.

Currently my only option is the make the module non-portable by either  
a) enforcing that luaopen_xxx only happens in the top-level state, or  
b) having an application-specific registry location in which the top- 
level state is cached.