Hi!
"Stewart" == Stewart Smith <stewart@flamingspork.com> writes:
Stewart> On Fri, Aug 14, 2009 at 10:28:35AM -0700, MARK CALLAGHAN wrote:
I describe how read/write is done for sockets in mysqld. http://www.facebook.com/note.php?note_id=122655300932
Can someone explain the history of this code?
A comment about the article: The common path for process_alarm is described wrongly - By default on Linux, USE_ONE_SIGNAL_HAND is set, which means that there is no pthread_sigmask() done for process_alarm() We also don't loop over all alarms, when we get an alarm; We only loop over the alarms that have timed out (it's a priority queue), so we find these very fast The alarm code is written with the assumption that there is very few alarms, in which case the LOCK_alarm mutex is mostly hold a very short time and process_alarm() is very seldom called. There should also be very few re-scheduling of alarms. While looking at the code, I did however find one hot spot when there is a lot of threads that could explain the contention for the mutex that you are talking of: Removing the alarm is done with a full loop over all alarms. It should not be too hard to use the priority queue to quickly find the alarm without having to go trough more than a fraction of the alarms. By doing this, you could get a major speedup in the case of many threads as the LOCK_alarm mutex is hold over a much shorter time. Mark, when you see the contention for the LOCK_alarm mutex, how many threads have you been running? As a separate note, I agree it would make perfect sense to use SO_SNDTIMEO on platforms that supports it, except for one little problem: We also use the thr_alarm() functionality when one uses 'kill connection-id' in MySQL. I don't know of any easy way to gracefully wake up a thread that is sleeping on SO_SNDTIMEO. Do you? Regards, Monty