On 9/3/10 9:34 AM, Sergei Golubchik wrote:
> Hi, LeeRicky!
> On Sep 03, LeeRicky wrote:
>> If my understanding is right, I think I should delay the creation of
>> all background threads util the storage engine handler's "init()"
>> function is called. InnoDB also has some io background threads, but
>> they are created in function "innobase_init()", just after mysql has
>> initilized handled signals. Am I right ?
> Please don't execute any code before mysql asks you to initialide the
> engine. This signal/mask is just one problem.
> Privileges is another - MySQL juggles with root privileges to execute
> most of the code as a non-privileged user, and still be able to use
> memlock() when everything is initialized. By starting your code from a
> static constructor you execute it with root user privileges, which
> basically means completely different level of audit and security
> requirements that your code should meet.
> Also, if you will ever want to support dynamic loading of your engine
> (with the INSTALL PLUGIN) then all static constructors will surely never
> be called, MySQL only calls init() callback of a plugin.
> MySQL does quite a lot to prepare execution environment before
> initializing engines - mutexes, memory allocators, performance
> instrumentation, command line options (current working directory too),
> error messages; if you start from a static constructor you have none of
> that, for example, performance instrumentation will not see your threads
> (or may even misbehave).
On a side note about the performance instrumentation ("PERFORMANCE
SCHEMA"), if you use the API mysql_thread_create() instead of
pthread_create(), the internal threads of your storage engine will be
visible in SQL in the performance_schema tables ...
See the code in the server for examples, or feel free to ask questions
on how to instrument code on this list.