connection_t = THD class?
it's a different structure/class?
i didn't read the source yet, just high level doubt...
It is a different class.
“Active” connections, i.e connections that currently are executing queries , can neither be found in threadpool’s waiting_threads, nor there is a different “active” list for them.
Where they are?
In the global “threads” list. IT is the list of THDs, not threads in the OS sense of it. Please disregard mixing “threads” with THDs, I know MySQL terminology gets confusing if one-thread-per-connection is not used.
If you see mentioning of “thread” in threadpool_xxx.cc, then you can be sure it is about OS threads. For example, waiting_threads list are OS threads, and not associated with any THDs.
ok i understood that we don't have a flag to show "active/not active" this should be done with a loop in threads to know if it's active or not, but what should i look? waiting_thread? queue? "processlist" threads?
Since you say “active/not active”, you’re talking about are connections, and not threads. The connections(THDs) are in the global “threads” list. You already know if they are active or not, nothing needs to be done for that.
In the current processlist, if Command=Sleep, then the connection is not active.
the thread group only have threads that are not executing, just queue and waiting_threads, and executing threads are outside thread pool?
I think you mixing something. Again, I remind that correct naming is when “thread” is OS thread, and not “THD”, or “connection”.
So back to the basics : Threadpool consist of worker threads. At any given moment, there are possibly some threads that do work, and there are other threads that are idle. Of those that are idle, typically one would be listening for network events . All threads are part of the threadpool. When a thread did some work, but became idle, because there is no work to do (all clients are idle), it adds itself to the list of “idle” threads, aka waiting_threads.
Other doubt... a waiting query (inside threadpool and not executing, inside "waiting_threads") is parsed, it have a THD structure or something that have the THD->lex? or it just have the network packages "saved in memory"? when it start execution it will be parsed and the THD will be executed?
Waiting threads do absolutely nothing. They wait until they are woken. They are not associated with THD, until they do some work. waiting_threads are not THD, those are OS threads that wait on condition variable.
Usually, a listener thread that I was talking above, will find out that there is some work, take an idle thread out of the waiting_threads list, hand it some work to do , and wake it..
So you may want to introduce special handling for those (i.e iterate the global “threads” list looking for active connections, get corresponding connection_t* struct from thd->event_scheduler.data, and do something with it, e.g look which thread group it belongs)
Hum, in this case should be more 'inteligent' have the thread_group at PROCESSLIST table? and a SQL SELECT could do the job at SQL Layer about "what connection is active"?
It's nice have a table with all thread, but i think it's the job of PROCESSLIST right? the point here is the THREAD_POOL information, in other words, now with you explain, we will have information about queue (connections without queries, maybe in sleep state) and connections waiting start (i don't know how is the state of this queries in processlist, do you know?)
PROCESSLIST is about connections, or THDs. It is not about OS threads. It just happened historically, that each THD in the past always had one thread, so the terminology got confusing.
In this case (add information at processlist), probably, we will have two kind of PROCESSLIST one for windows and other for unix, i'm right or wrong?
Well, I would prefer not to have more in processlist than there is now. And I do not like to have different processlist for different OSes.
<skip>
On Windows, I doubt you can implement any information_schema plugin for the threadpool. This is because threadpool is native OS threadpool, and OS structure representing it PTP_POOL structure is opaque, and there is not much info you can extract from it (well, maybe you can , if you debug with a kernel debugger, but not otherwise)
Windows will be a other MDEV (https://mariadb.atlassian.net/browse/MDEV-5046) =)
let's start with linux, it's easier than windows hehehe :P
This is wrong, when you talk about threadpool. Windows implementation is half of Unix in terms of lines of code, and one tens in terms of complexity. Windows can also be half of what it is now (in LOCS), if I we would to need to run on XP.
Unix implementation is also much more complicated than it had to be, because it is built as a workaround for not scaling multithreaded Linux epoll (http://markmail.org/message/piebp4xosrjv6w7k ). There would not be any need for thread groups and complicated stuff list that, if multithreaded epoll worked.
Wlad
From: Maria-developers [mailto:maria-developers-bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Roberto Spadim
Sent: Montag, 16. September 2013 21:20
To: maria-developers@lists.launchpad.net
Subject: [Maria-developers] MDEV-5019 - THREADPOOL - Create Information Schema Table for Threadpool
Hi guys!
I openned a new MDEV https://mariadb.atlassian.net/browse/MDEV-5019 the idea is expose the threadpool group information like oracle thread pool (more information about oracle thread pool here: http://mikaelronstrom.blogspot.com.br/2011_10_01_archive.html)
I can help, but i don't know how access the threadpool at scheduler.h/scheduler.c from a information schema plugin
1) lock important mutex and others mdl
2) acess variables
3) write information schema based on variables
1 and 2 i don't know how to do :(
can anyone help ? :)
thanks guys :)
--
Roberto Spadim
--
Roberto Spadim
SPAEmpresarial