BUG#11752315 - 43460: STOP SLAVE UNABLE TO COMPLETE WHEN SLAVE THREAD IS TRYING TO RECONNECT TO

Problem : The basic problem is the way the thread sleeps in mysql-5.5 and also in mysql-5.1
          when we execute a stop slave on windows platform.
          On windows platform if the stop slave is executed after the master dies, we have 
          this long wait before the stop slave return a value. This is because there is a 
          sleep of the thread. The sleep is uninterruptable in the two above version,
          which was fixed by Davi patch for the BUG#11765860 for mysql-trunk. Backporting 
          his patch for mysql-5.5 fixes the problem. 

Solution : A new pair of mutex and condition variable is introduced to synchronize thread 
           sleep and finalization. A new mutex is required because the slave threads are 
           terminated while holding the slave thread locks (run_lock), which can not be 
           relinquished during termination as this would affect the lock order.

1 files changed, 2 insertions, 4 deletions

diff --git a/sql/rpl_rli.h b/sql/rpl_rli.h
index c8a0f549e0f..6e0a100fca7 100644
--- a/sql/rpl_rli.h
+++ b/sql/rpl_rli.h
@@ -138,15 +138,13 @@ public:
     standard lock acquisition order to avoid deadlocks:
     run_lock, data_lock, relay_log.LOCK_log, relay_log.LOCK_index
   */
-  mysql_mutex_t data_lock, run_lock;
-
+  mysql_mutex_t data_lock, run_lock, sleep_lock;
   /*
     start_cond is broadcast when SQL thread is started
     stop_cond - when stopped
     data_cond - when data protected by data_lock changes
   */
-  mysql_cond_t start_cond, stop_cond, data_cond;
-
+  mysql_cond_t start_cond, stop_cond, data_cond, sleep_cond;
   /* parent Master_info structure */
   Master_info *mi;