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).