| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Also add develop branch's comments about llcoro::LockType being deprecated.
|
|
|
|
|
|
(#2507)
|
|
|
|
Changes on new main and changes on Lua project branch combined into a header
circularity. Resolved by hoisting coroutine-aware synchronization primitives
out to a new llcoromutex.h file in the `llcoro` namespace, rather than being
literally members of the `LLCoros` class. But retained `using` declarations in
`LLCoros` for backwards compatibility.
|
|
|
|
|
|
secondlife/viewer#2445
|
|
|
|
and Beq (#2423)
|
|
|
|
|
|
|
|
|
|
Otherwise, an exception raised in the block containing a LuaStackDelta
instance -- that might be caught -- would result in an LL_ERRS() crash. We
can't expect a block exited via exception to keep its contract wrt the Lua
data stack.
|
|
Use a static unordered_map to allow a function receiving (lua_State* L) to
look up the LuaState instance managing that lua_State. We've thought about
this from time to time already. LuaState's constructor creates the map entry;
its destructor removes it; the new static getParent(lua_State* L) method
performs the lookup.
Migrate lluau::set_interrupts_counter() and check_interrupts_counter() into
LuaState member functions. Add a new mInterrupts counter for them.
Importantly, LuaState::check_interrupts_counter(), which is indirectly called
by a lua_callbacks().interrupt function, no longer performs any Lua stack
operations. Empirically, it seems the Lua engine is capable of interrupting
itself at a moment when re-entry confuses it.
Change previous lluau::set_interrupts_counter(L, 0) calls to
LuaState::getParent(L).set_interrupts_counter(0).
Also add LuaStackDelta class, and a lua_checkdelta() helper macro, to verify
that the Lua data stack depth on exit from a block differs from the depth on
entry by exactly the expected amount. Sprinkle lua_checkdelta() macros in
likely places.
|
|
In fact we set mOldValue from mVar, and restore mVar from mOldValue, so the
VAR type makes the most sense. The previous way, you'd get actual errors if
you tried to use TempSet(pointervar, nullptr): that declared mOldValue to be
nullptr_t, which you can't initialize from mVar.
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llvoicewebrtc.cpp
|
|
code in PCH (#2361)
|
|
|
|
|
|
|
|
release/2024.06-atlasaurus
|
|
|
|
|
|
luaL_checkstack() accepts a third parameter which is included in the stack
overflow error message. We've been passing nullptr, leading to messages of the
form "stack overflow ((null))". lluau_checkstack() implicitly passes
__FUNCTION__, so we can distinguish which underlying luaL_checkstack() call
encountered the stack overflow condition.
Also, when calling each atexit() function, pass Luau's debug.traceback()
function as the lua_pcall() error handler. This should help diagnose errors in
atexit() functions.
|
|
* Enable /permissive- on MSVC for better C++ conformance and fix related errors
* Clean up left over warning suppressions from old library or msvc versions
|
|
and logging
|
|
configurable at build time
Also copy tracy profiler client next to windows binary when enabled
|
|
Add Throttle and LogThrottle classes to manage throttled APIs.
|
|
|
|
|
|
# Conflicts:
# .github/workflows/build.yaml
# indra/llui/llscrolllistctrl.cpp
|
|
release/2024.06-atlasaurus
# Conflicts:
# .github/workflows/build.yaml
# indra/newview/CMakeLists.txt
# indra/newview/llspeakers.cpp
# indra/newview/llvoicechannel.cpp
# indra/newview/llvoicechannel.h
# indra/newview/llvoiceclient.cpp
# indra/newview/llvoiceclient.h
# indra/newview/llvoicewebrtc.cpp
|
|
Add test_flycam.lua to exercise the smaller intervals.
|
|
|
|
|
|
The viewer's main thread's main fiber is responsible for coordinating just
about everything. With the default round_robin fiber scheduling algorithm,
launching too many additional fibers could starve the main fiber, resulting in
visible lag.
This custom scheduler tracks when it switches to and from the main fiber, and
at each context switch, how long it's been since the last time the main fiber
ran. If that exceeds a certain timeslice, it jumps the main fiber to the head
of the queue and resumes that instead of any other ready fiber.
|
|
|
|
Leverage C++ overloads to allow use of generic function names disambiguated by
argument type.
This allows using templates for certain common operation sequences.
|
|
|
|
|
|
Fix for tracy build.
|
|
|
|
`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.
|
