clayborg added a comment. These completion requests are also expected to be asynchronous right? Do we have any support for this right now? Currently we will deadlock in lldb-vscode handling the current completion until it completes right? To properly handle completion, we will need to be able to cancel a current completion and only remember the last completion that was sent and throw away any intermediate completions. Did we add support for that already, or do we read the first completion command, and then block until it completes and return the response, then handle any others.
IIUC if we get a completion for: "hello", we will go off and start trying to complete this, we might, while trying to complete "hello" get new requests in for "hello w" and "hello wo" and "hello wor" and "hello worl" queued up. If we have no async support, we will need to mark such packets as asynchronous, add the ability to cancel a completion if we don't already have that in the SBCommandInterpreter::HandleCompletion(...) functions, and then only remember the last unhandled completion "hello worl" in this case and respond with error to the first "hello" (canceled due to new completion that came in), "hello w", "hello wo" and "hello wor" since we won't try to complete those because new completions came in after these, and then issue the "hello worl" completion and respond as needed. We might also think about putting a timeout in the completion code, so we don't even try to complete for a specific amount of time (1 second) so we could watch for new completions to come up. Do we know if the completion was just because someone was typing or if they requested it with CTRL-space? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74264/new/ https://reviews.llvm.org/D74264 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
