tfiala added a comment. My guess here would be that the fixing of the race - i.e. ensuring the listening side is up and running before allowing the sender to continue, is probably keeping more sockets open than before (i.e. fixing the race, but doing so by using an average larger number of resources).
There are at least a couple ways to solve that, if that indeed is the issue: 1. Don't run as many threads on Windows (set --threads 24 or 32), 2. We abstract the communication mechanism, and use something different on Windows and/or something better for all, that allows bi-directional communication and isn't as limited. The "something different" could be a file based approach or some kind of other IPC mechanism. The key is it needs to be compatible with the asyncore approach used as part of the main loop in dosep.py. What you probably don't want to do is revert this on Windows, since it is likely ensuring some test events come in that were getting dropped before. If you end up getting excessively stuck on this, I'd suggest doing #1 to eliminate the limit from being hit, while a better solution for #2 is worked out for Windows. (And if you get stuck on #2, let me know, I may be able to dig around a bit and help, or at least get a test suite for that part up so you can plug in an implementation that works). http://reviews.llvm.org/D19214 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
