labath wrote: 20 attempts is already more than what I would consider reasonable. Increasing it doesn't sound like a good idea. If the problem is lingering sockets, then I think a better approach is to slow down the rate of socket creation, not churn out more of them.
While this code tries to back off, it doesn't implement the (standard?) *exponential* backoff algorithm. I think that's important, as without it, it just ends up churning out more and more connections at a relative fast rate (`time.sleep(random.randint(1, 5))` gives you an average of 3s, so this may even be faster than "running a test" -- which also generates a new socket. And since this happens a few times, I wouldn't be surprised if that's during the times that the random generator generates a locally-lower-than-average sequence of random numbers). So, the thing I'd do is use a proper exponential algorithm and *reduce* the retry count (so that the total wait time ends up being slightly more than what it is now), and also increase the range of ports that we're picking from (I don't know how the `12000 + random.randint(0, 3999)` thingy was chosen, but I think we could increase that any issues). (Of course, a much better solution would be to either let lldb-server pick a free port (and communicate it back to the test somehow) or to reuse the socket multiplexing approach we (you) recently implemented. That may not work for all tests (we still need to test the user-provided-port scenario somehow), but 99% of the tests don't care about the connection method, o if we can solve the problem for the majority of tests, then this alleviates the pressure on the minority that does need it.) https://github.com/llvm/llvm-project/pull/118222 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
