From 2a5d8ea9a201a1bf33fe309b8293e31ebd961e60 Mon Sep 17 00:00:00 2001 From: Vladislav Vaintroub Date: Fri, 17 Feb 2012 23:27:15 +0100 Subject: Added copiright, some more comments --- sql/threadpool_unix.cc | 46 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 6 deletions(-) (limited to 'sql/threadpool_unix.cc') diff --git a/sql/threadpool_unix.cc b/sql/threadpool_unix.cc index ad44e237262..407905fd5f6 100644 --- a/sql/threadpool_unix.cc +++ b/sql/threadpool_unix.cc @@ -1,3 +1,18 @@ +/* Copyright (C) 2012 Monty Program Ab + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; version 2 of the License. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ + #include #include #include @@ -541,6 +556,29 @@ void check_stall(thread_group_t *thread_group) /* Check whether requests from the workqueue are being dequeued. + + The stall detection and resolution works as follows: + + 1. There is a counter thread_group->queue_event_count for the number of + events removed from the queue. Timer resets the counter to 0 on each run. + 2. Timer determines stall if this counter remains 0 since last check + and the queue is not empty. + 3. Once timer determined a stall it sets thread_group->stalled flag and + wakes and idle worker (or creates a new one, subject to throttling). + 4. The stalled flag is reset, when an event is dequeued. + + Q : Will this handling lead to an unbound growth of threads, if queue + stalls permanently? + A : No. If queue stalls permanently, it is an indication for many very long + simultaneous queries. The maximum number of simultanoues queries is + max_connections, further we have threadpool_max_threads limit, upon which no + worker threads are created. So in case there is a flood of very long + queries, threadpool would slowly approach thread-per-connection behavior. + NOTE: + If long queries never wait, creation of the new threads is done by timer, + so it is slower than in real thread-per-connection. However if long queries + do wait and indicate that via thd_wait_begin/end callbacks, thread creation + will be faster. */ if (!thread_group->queue.is_empty() && !thread_group->queue_event_count) { @@ -1250,10 +1288,7 @@ void tp_post_kill_notification(THD *thd) void tp_wait_begin(THD *thd, int type) { DBUG_ENTER("tp_wait_begin"); - - if (!thd) - DBUG_VOID_RETURN; - + DBUG_ASSERT(thd); connection_t *connection = (connection_t *)thd->event_scheduler.data; if (connection) { @@ -1272,8 +1307,7 @@ void tp_wait_begin(THD *thd, int type) void tp_wait_end(THD *thd) { DBUG_ENTER("tp_wait_end"); - if (!thd) - DBUG_VOID_RETURN; + DBUG_ASSERT(thd); connection_t *connection = (connection_t *)thd->event_scheduler.data; if (connection) -- cgit v1.2.1