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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
