[Lldb-commits] [lldb] [lldb-dap] Refactor lldb-dap event handling. (PR #139669)

[Pavel Labath via lldb-commits]

labath wrote:

> I think our tests are not fully specifying their expected state. For example, lldb/test/API/tools/lldb-dap/console/TestDAP_console.py `TestDAP_console.test_diagnositcs` was performing an evaluate and then using `get_important` to fetch output events with category 'important'.
> 
> With the change, the `important` output was always coming after the request was handled. I updated the test to use a `self.collect_important` instead of `get_important`. Previously, this could have been emitted while the request was being handled, but now the output would only ever be emitted after the request handler is finished.

Okay, so it's kind of what I said, right? The "important" output was coming before the message was handled most of the time, although it wasn't guaranteed, and the test could fail if that happens. Now, it *always* comes too late.

If that's true, then the test change to use `self.collect_important` could be made before the functionality change, right?


> Thinking about this some more, would it be possible to treat everything as an `SBEvent`? We could use the `DAP::broadcaster` to create events for the DAP protocol messages we receive, right? Then when we listen for events we'd just need to check if the event was a `DAPBroadcasterBits::eBroadcastBitProtocolMessage` as the event type and handle protocol messages in the same loop we're handling events.
> 
> This would have a similar effect as using a MainLoop but unifies the event thread with the DAP handler. We'd still need to transport thread to parse messages and add events to the broadcaster.

Yeah, that should be possible, and it may make more sense in a world where the MainLoop cannot listen on all FD types (since you need the forwarding thread anyway). It's unfortunate that there's no synchronization operation (at least, not a portable one, FUTEX_FD seems kinda nice) that allows you do wait for condition variables and FDs, necessitating these forwarding threads. Since forwarding would add a bit of latency, one of the factors would be which kinds of operations do we want to make slower.

https://github.com/llvm/llvm-project/pull/139669