lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Sat, Jun 6, 2009 at 7:02 PM, Wesley Smith<> 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

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.