Ensure consistent thread usage of ICaptureAccess in the UI

* We could put everything onto the replay thread but that's unnecessary back-
  and-forth pingponging for a local capture.
* This is safe to use on the UI thread if it's local, but if it's remote it uses
  the same connection as the replay controller so must happen on the replay
  thread.
* We add a new helper (not exposed to swig) that handles this check, and for
  python we wrap the returned ICaptureAccess in an invoker that ensures we are
  on one of those threads.
This commit is contained in:
baldurk committed 2026-10-23 23:13:16 +01:00
1 parent 198bd9d673
commit 39be707fde
6 files changed
+333 -103

No files matched your search

+4 -9
View File
@@ -180,16 +180,11 @@ void APIInspector::on_apiEvents_itemSelectionChanged()
if(chunk && !chunk->metadata.callstack.isEmpty())
{
if(m_Ctx.Replay().GetCaptureAccess())
{
m_Ctx.Replay().AsyncInvoke([this, chunk](IReplayController *) {
rdcarray<rdcstr> stack =
m_Ctx.Replay().GetCaptureAccess()->GetResolve(chunk->metadata.callstack);
if(!m_Ctx.Replay().AsyncAccessInvoke([this, chunk](ICaptureAccess *access) {
rdcarray<rdcstr> stack = access->GetResolve(chunk->metadata.callstack);
GUIInvoke::call(this, [this, stack]() { addCallstack(stack); });
});
}
else
GUIInvoke::call(this, [this, stack]() { addCallstack(stack); });
}))
{
ui->callstack->setUpdatesEnabled(false);
ui->callstack->clear();