Brandon Nesterenko <brandon.nesterenko@mariadb.com> writes:
+ wait_result= cond_timewait(front.thd, &abstime);
I'm wondering, is it safe here to wait on front.thd->COND_wakeup_ready? Isn't there a possibility that this might go away during the wait?
I thought about that originally, and I don't think it can go away, as we have a lock on changes in the wait_queue (to be Active_tranx), and for
But cond_timewait() releases the lock during the wait. Yes, the THD will be valid when we _start_ the wait. But what if the condition is signalled, the shutdown thread is delayed in scheduling for some reason, and the front.thd thread wakes up and exits? Then when the shutdown thread eventually wakes up, it will be waking up on a pthread_cond_t that's potentially freed at that point, right? Or is there some mechanism that makes all threads delay their exit until the shutdown-semisync-wait has completed?
I don't understand this. Why shouldn't a session waiting for ACK be killable? On the contrary, such a wait can take potentially a long time, seems important that it can be killed?
So the idea with my fix is that, once we have noted the update to the binary log, we immediately mark in thd->is_awaiting_semi_sync_ack, so the shutdown will await its ACK.
Aha, thanks for the explanation (I had mis-understood the code here).
Is this suppression needed? If so, why?
If I remember right, when the slave io thread stops, the master's ACK receiver can log that error when trying to read from the socket. Though note this is
Ok, should be fine, I was just wondering. - Kristian.