On Wed, Mar 10, 2010 at 12:29 PM, Michael Widenius <monty@askmonty.org> wrote:
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?
I have to revisit this. I will reply again when I have data to share.
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?
No, although I haven't looked and I don't do much network systems programming. -- Mark Callaghan mdcallag@gmail.com