labath added a comment. In D131159#3707741 <https://reviews.llvm.org/D131159#3707741>, @mstorsjo wrote:
> I don't really have experience with this API - is this pattern (creating and > closing event objects for each poll run) the common way of using this API? Is > there any potential performance risk compared with keeping event objects > around (if that's possible?). Well.. I can't exactly say I'm familiar with the APIs either, but I suspect this is not the "common" way of using them. It is, however, the closest I could get to the purely level-triggered behavior that one gets with select/poll on unix. Normally (with event reuse), windows requires that one calls the "reset" function (e.g. `recv`) at least once (the call itself is sufficient, it does not have to actually read all pending data) before the event can be triggered again. I think possible that nothing depends on this behavior (or could be fixed to not depend on it) -- after all you're usually doing this because you actually want to read from the socket. However, we did have one unit test which relied on this. That was mostly because it was being lazy (testing other things), but I wanted to start out with something safe-ish. As for performance, it's definitely slower than not creating the events every time around, but I doubt that difference would be noticeable. However, now that I think about it, I think the repeating the call to `WSAEventSelect` should be sufficient to get the level-triggered behavior, even if it's just reusing the same event object. Let me try how that works. > Can @alvinhochun take the patch for a spin? I think you've got more realistic > usecases of lldb to try it out in. (Do you want me to make a build with the > patch for you to try out?) @labath What's the best way to exercise this code > in actual use of lldb? I would appreciate that. I have tried to build it and run the test suite, but I didn't have a clean baseline, so I can't really say whether it works for everything. The main user of this code is the gdb-remote communication code, so debugging something via lldb-server (or running the lldb-server test suite) should be a good indicator of whether it works. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131159/new/ https://reviews.llvm.org/D131159 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
