[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: retrieve top-level lua_State?
- From: Graham Wakefield <lists@...>
- Date: Sat, 6 Jun 2009 14:43:20 -0700
On Jun 6, 2009, at 12:28 PM, Peter Cawley wrote:
On Sat, Jun 6, 2009 at 7:02 PM, Wesley Smith<email@example.com>
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.