| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Leverage C++ overloads to allow use of generic function names disambiguated by
argument type.
This allows using templates for certain common operation sequences.
|
|
`LLEventAPI` is specifically intended to allow a LEAP plugin, or a Lua script,
to access certain viewer functionality. Errors in external code like that
cannot be addressed during viewer development. Any code path that allows
external code in any form to crash the viewer opens up a potential abuse
vector, if a trusting user runs external code from an untrustworthy source.
`LLDispatchListener` reports exceptions back to its invoker, if the invoker
provides a "reply" `LLEventPump` name. Absent "reply", though,
`LLDispatchListener` is documented to let any such exception propagate. That
behavior may be okay for internal use, but in the case of the `LLEventAPI`
subclass, it veers into the abuse scenario described above.
Make `LLEventAPI` ensure that any exception propagating from `LLDispatchListener`
is caught and logged, but not propagated.
Also enrich error reporting for the "batch" `LLDispatchListener` operations.
|
|
Remove documented `LLEventPump` support for `LLEventTrackable`. That claimed
support was always a little bit magical/fragile. IF:
* a class included `LLEventTrackable` as a base class AND
* an instance of that class was managed by `boost::shared_ptr` AND
* you passed one of that class's methods and the `boost::shared_ptr`
specifically to `boost::bind()` AND
* the resulting `boost::bind()` object was passed into `LLEventPump::listen()`
THEN the promise was that on destruction of that object, that listener would
automatically be disconnected -- instead of leaving a dangling pointer bound
into the `LLEventPump`, causing a crash on the next `LLEventPump::post()` call.
The only existing code in the viewer code base that exercised `LLEventTrackable`
functionality was in test programs. When the viewer calls `LLEventPump::listen()`,
it typically stores the resulting connection object in an `LLTempBoundListener`
variable, which guarantees disconnection on destruction of that variable.
The fact that `LLEventTrackable` support is specific to `boost::bind()`, that it
silently fails to keep its promise with `std::bind()` or a lambda or any other
form of C++ callable, makes it untrustworthy for new code.
Note that the code base still uses `boost::signals2::trackable` for other
`boost::signals2::signal` instances not associated with `LLEventPump`. We are
not changing those at this time.
|
|
`listen()` still takes `LLEventListener`, a `callable(const LLSD&)`, but now
also accepts `LLAwareListener`, a `callable(const LLBoundListener&, const LLSD&)`.
This uses `boost::signals2::signal::connect_extended()`, which, when the
signal is called, passes to a connected listener the `LLBoundListener` (aka
`boost::signals2::connection`) representing its own connection. This allows a
listener to disconnect itself when done.
Internally, `listen_impl()` now always uses `connect_extended()`. When passed
a classic `LLEventListener`, `listen()` wraps it in a lambda that ignores the
passed `LLBoundListener`.
`listen()` also now accepts `LLVoidListener`, and internally wraps it in a lambda
that returns `false` on its behalf.
|
|
We couldn't discard the "p.s." fiber.run() call from LuaState::expr() until we
could count on fiber.lua's LL.atexit(fiber.run) call being executed after each
Lua script or chunk, and we couldn't count on that until we made
LLLUAmanager::runScriptFile() instantiate and destroy its LuaState on the C++
Lua-specific coroutine. Now that we've done that, use LL.atexit(fiber.run)
instead of the whole special-case "p.s." in LuaState::expr().
|
|
Remove LLLUAmanager::mumbleScriptLine() LuaState& parameters. Make
startScriptLine(), waitScriptLine() and runScriptLine() exactly parallel to
startScriptFile(), waitScriptFile() and runScriptFile(). That means that
runScriptLine()'s C++ coroutine instantiates and destroys its own LuaState,
which means that LL.atexit() functions will run on the Lua-specific C++
coroutine rather than (say) the viewer's main coroutine.
Introduce LLLUAmanager::script_result typedef for std::pair<int, LLSD> and use
in method returns.
Remove LuaState::initLuaState(); move its logic back into the constructor.
Remove initLuaState() calls in the expr() error cases: they're moot now that
we won't get subsequent expr() calls on the same LuaState instance.
Remove LLFloaterLUADebug "Use clean lua_State" checkbox and the cleanLuaState()
method. Remove mState member.
Remove explicit LuaState declarations from LLLUAmanager tests. Adapt one test
for implicit LuaState: it was directly calling LuaState::obtainListener() to
discover the LuaListener's reply-pump name. But since that test also captures
two leap.request() calls from the Lua script, it can just look at the "reply"
key in either of those requests.
|
|
Use LLSDParam<uuid_vec_t> in LLAppearanceListener::wearItems() and
detachItems() to build the vector of LLUUIDs from the passed LLSD array.
|
|
These encapsulate looping over a C++ iterable (be it a sequence container or
an associative container) and returning an LLSD array or map, respectively,
derived from the C++ container. By default, each C++ container item is
directly converted to LLSD.
Also make LLSDParam<LLSD> slightly more efficient by using
std::vector::emplace_back() instead of push_back(), which supports
std::vector<std::unique_ptr>, so we need not use std::shared_ptr.
|
|
|
|
This is redundant (but harmless) on a Posix system, but it fills a missing
puzzle piece on Windows. The point of fsyspath is to be able to interchange
freely between fsyspath and std::string. Existing fsyspath could be
constructed and assigned from std::string, and we could explicitly call its
string() method to get a std::string, but an implicit fsyspath-to-string
conversion that worked on Posix would trip us up on Windows. Fix that.
|
|
This replaces type_tag<T>(), which searched and possibly extended the type_tags
unordered_map at runtime. If we called lua_emplace<T>() from different threads,
that would require locking type_tags.
In contrast, the compiler must instantiate a distinct TypeTag<T> for every
distinct T passed to lua_emplace<T>(), so each gets a distinct value at static
initialization time. No locking is required; no lookup; no allocations.
Add a test to llluamanager_test.cpp to verify that each distinct T passed to
lua_emplace<T>() gets its own TypeTag<T>::value, and that each gets its own
destructor -- but that different lua_emplace<T>() calls with the same T share
the same TypeTag<T>::value and the same destructor.
|
|
It turns out that Luau does not honor PUC-Rio Lua's __gc metafunction, so
despite elaborate measures, the previous lua_emplace<T>() implementation would
not have destroyed the contained C++ T object when the resulting userdata
object was garbage-collected.
Moreover, using LL.atexit() as the mechanism to destroy lua_emplace<T>()
userdata objects (e.g. LuaListener) would have been slightly fragile because
we also want to use LL.atexit() to make the final fiber.run() call, when
appropriate. Introducing an order dependency between fiber.run() and the
LuaListener destructor would not be robust.
Both of those problems are addressed by leveraging one of Luau's extensions
over PUC-Rio Lua. A Luau userdata object can have an int tag; and a tag can
have an associated C++ destructor function. When any userdata object bearing
that tag is garbage-collected, Luau will call that destructor; and Luau's
lua_close() function destroys all userdata objects.
The resulting lua_emplace<T>() and lua_toclass<T>() code is far simpler.
It only remains to generate a distinct int tag value for each different C++
type passed to the lua_emplace<T>() template.
unordered_map<std::type_index, int> addresses that need.
|
|
The help string for each lua_function() must restate the function name and its
arguments. The help string is all that's shown; unless it restates the
function name, LL.help() output lists terse explanations for functions whose
names are not shown.
Make help() prepend "LL." to help output, because these functions must be
accessed via the "builtin" LL table instead of directly populating the global
Lua namespace.
Similarly, before string name lookup, remove "LL." prefix if specified.
|
|
|
|
|
|
On Mac it doesn't seem to matter, but on Windows, leaving it uninitialized can
produce garbage results and even crash the coroutine. This seems strange,
since we've been assuming lua_getinfo() treats its lua_Debug* as output-only.
|
|
We might decide to leave some of them in place.
|
|
Instead, make fiber.lua call LL.atexit(fiber.run) to schedule that final run()
call at ~LuaState() time using the generic mechanism.
Append an explicit fiber.run() call to a specific test in llluamanager_test.cpp
because the test code wants to interact with multiple Lua fibers *before* we
destroy the LuaState.
|
|
so cleanup happens in reverse order, as is conventional.
Streamline LL.atexit() function: luaL_newmetatable() performs all the
find-or-create named Registry table logic.
|
|
lua_emplace<T>() was passing LL.atexit() a closure binding the new userdata
with a cleanup function. The trouble with that was that a strong reference to
the new userdata would prevent it ever being garbage collected, even if that
was the only remaining reference.
Instead, create a new weak table referencing the userdata, and bind that into
the cleanup function's closure. Then if the only remaining reference to the
userdata is from the weak table, the userdata can be collected.
Make lua_emplace_call_gc<T>() check the bound weak table in case the userdata
has in fact been collected.
Also, in lua_toclass<T>(), use luaL_checkudata() to synopsize comparing the
putative userdata's metatable against the one synthesized by lua_emplace<T>().
This saves several explicit steps.
|
|
source_path() previously reported the path of the module containing the
current (lowest-level) Lua function. The effect was that the Floater.lua
module would always try to look up the XUI file relative to
scripts/lua/require.
It makes more intuitive sense to make source_path() return the path containing
the top-level script, so that a script engaging the Floater.lua module looks
for the XUI file relative to the script.
|
|
Instead of deriving LuaListener from LLInstanceTracker with an int key,
generating a unique int key and storing that key in the Registry, use new
lua_emplace<LuaState>() to store the LuaListener directly in a Lua userdata
object in the Lua Registry.
Because lua_emplace<T>() uses LL.atexit() to guarantee that ~LuaState will
destroy the T object, we no longer need ~LuaState() to make a special call
specifically to destroy the LuaListener, if any. So we no longer need
LuaState::getListener() separate from obtainListener().
Since LuaListener is no longer an LLInstanceTracker subclass, make
LuaState::obtainListener() return LuaListener& rather than LuaListener::ptr_t.
|
|
Publish new LL.atexit() function that accepts a Lua function (or C++ closure)
and saves it (in Registry["atexit"] table) to call later.
Make ~LuaState() walk the Registry["atexit"] table, if it exists, calling each
function appended to that table.
(Consider using that mechanism to clean up a LuaListener, if one was
instantiated. Possibly also use for p.s. leap.run()? But that's run after
every expr() call, instead of only at ~LuaState() time. Pragmatically, though,
the distinction only matters for a LUA Debug Console LUA string with "clean
lua_State" unchecked.)
For use by future lua_function() entry points, lua_emplace<T>(ctor args...)
pushes a Lua userdata object containing a newly-constructed T instance --
actually a std::optional<T> to avoid double destruction. lua_emplace<T>() is
specifically intended to be usable even for T with a nontrivial destructor: it
gives the userdata a metatable with a __gc function that destroys the
contained T instance when the userdata is garbage collected. But since garbage
collection doesn't guarantee to clean up global variables with __gc methods,
lua_emplace<T>() also uses LL.atexit() to ensure that ~T() will run when the
LuaState is destroyed.
The companion to lua_emplace<T>() is lua_toclass<T>(), which returns a
non-nullptr T* if the referenced index is in fact a userdata created by
lua_emplace<T>() for the same T, that has not yet been destroyed. This lets
C++ code access a T previously embedded in Lua userdata.
|
|
We have log messages when a coroutine terminates abnormally, but we don't
report either when it starts or when it terminates normally. Address that.
|
|
It's helpful to see when expr() is actually going to start running a
particular Lua chunk. We already report not only when it's done, but also
if/when we start and finish a p.s. fiber.run() call.
|
|
|
|
to pick up Featurettes promotion + Brad's GitHub Windows build workaround.
|
|
#648: Release/materials featurette
|
|
|
|
|
|
|
|
instead of using mutual recursion to exhaust the read buffer.
|
|
|
|
|
|
The reqid is only distinct within a particular calling script.
|
|
Since timers presents a timers.Timer Lua class supporting queries and
cancellation, make TimersListener::scheduleAfter() and scheduleEvery() respond
immediately so the newly constructed Timer object has the reqid necessary to
perform those subsequent operations.
This requires that Lua invocations of these operations avoid calling the
caller's callback with that initial response.
Reinvent leap.generate() to return a Lua object supporting next() and done()
methods. A plain Lua coroutine that (indirectly) calls fiber.wait() confuses
the fiber scheduler, so avoid implementing generate() as a Lua coroutine.
Add a bit more leap.lua diagnostic output.
|
|
|
|
|
|
Otherwise we fall into the trap of destroying a joinable std::thread, which
calls std::terminate() and hence our crash-on-terminate() handler.
The previous ~ThreadPool() logic only joined threads if the queue wasn't
already closed, but evidently we can reach the destructor with the queue
closed but the threads not yet joined.
Fixes #1534.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
