The thing to be concerned about here is whether it is possible to find a code path that attempts to acquire the coordinator lock while holding the client lock. Unfortunately, I think this is super tricky because even though we have deferred processing of futures that handle connection responses into an unlocked pending_completions list, there are loads of other futures that are not in this list. Now, most of these are not going to get generated while the client lock is acquired (see git grep future.success). But a very real risk is future.failure(). An obvious place where this might happen is during KafkaClient._maybe_connect, which acquires the client lock and then calls into the BrokerConnection.connect function. If something goes wrong during connect, we will call self.close() and that will cause all in-flight-request futures to be immediately failed. That will cause errbacks to run with the client lock acquired, and if one of those errbacks ends up attempting to acquire the coordinator lock, for example in _handle_join_failure or _handle_heartbeat_failure, then we could get a deadlock.

The java client uses its RequestFutureCompletionHandler to shim these connection failures onto the pending completions queue, in order to avoid the problem of errbacks running while the client lock is acquired. I expect that we will need to implement something similar to really get this under control.

I haven't found any specific paths that would trigger a deadlock with this change. The example I mentioned above would require that somehow we get an in-flight-request before the connection is completed. That shouldn't happen, so I'm going to merge and keep an eye out for any other issues.

I also think that the repair method you suggested is more thorough and better, and my method is relatively simple, in order to quickly repair production problems.
When the heartbeat thread uses 2 keys to call client.poll to read data, the performance of the main consumer thread is less affected. I have tested the performance.
I hope you can use a better way to solve the design problem of multi-threaded shared client.poll