Hi Roberto,I do believe the idea of the thread pool was to get rid of the one thread/connection paradigm, so all connections will be served by potentially all threads.
CREATE TABLE `PROCESSLIST` (
`ID` BIGINT(4) NOT NULL DEFAULT '0' COMMENT "INTERNAL CONNECTION ID or something better?",
`QUERY_ID` BIGINT(4) NOT NULL DEFAULT '0',
`USER` VARCHAR(128) NOT NULL DEFAULT '',
`HOST` VARCHAR(64) NOT NULL DEFAULT '',
`DB` VARCHAR(64) NULL DEFAULT NULL,
`COMMAND` VARCHAR(16) NOT NULL DEFAULT '',
`TIME` INT(7) NOT NULL DEFAULT '0',
`STATE` VARCHAR(64) NULL DEFAULT NULL,
`INFO` LONGTEXT NULL,
`TIME_MS` DECIMAL(22,3) NOT NULL DEFAULT '0.000',
`STAGE` TINYINT(2) NOT NULL DEFAULT '0',
`MAX_STAGE` TINYINT(2) NOT NULL DEFAULT '0',
`PROGRESS` DECIMAL(7,3) NOT NULL DEFAULT '0.000',
`MEMORY_USED` INT(7) NOT NULL DEFAULT '0',
`EXAMINED_ROWS` INT(7) NOT NULL DEFAULT '0'
)
COLLATE='utf8_general_ci'
ENGINE=Aria;
Each group in itself is a complete small pool with a listener thread (the one waiting for network events) , work queue (is it a thread or a shared memory?) and worker threads (see the "s"? threads, more than one worker thread).
A group has the responsibility of keeping one thread running, if there is a work to be done. More than one thread in a group can be running, depending on circumstances (more about this later). Clients are assigned to the groups in a round-robin fashion (here my doubt, what client is running in what thread pool group?). This will keep (statistically) about the same ratio of clients per group. Listener and worker roles are dynamically assigned. Listener can become worker, after waiting for network events; it can pick an event and handle thus it becoming a worker. Vice versa, once worker is finished processing a query, it can become listener.