My team is developing a new storage engine. During our test, we always foud the warning message "Got signal 14 from thread 0" in mysqld.log. The warning messages is received every several seconds. It has confused us for a long time.
Recently I checked our code carefully and I think I have found the problem.
From the mysql reference manual, I found this:
"A signal thread handles all signals. This thread also normally handles alarms and calls process_alarm() to force timeouts on connections that have been idle too long."
Our system needs several background threads to work properly, and their owners are defined as static global variables.
In the beginning, the static global variables are initialized, then its constructor is called and the background threads start, It inherits signal mask from the process's main thread. This happens early before the main thread initializes signals that the signal handle thread should deal with. So the signal mask need to be set isn't set in our background threads.
As we see, the signal handle thread can't intercept all signals received by the main thread in this case. When a SIGALARM signal is sent to the main thread, the signal action registered by the process is called and prints the warning. This is not safety work.
1、I just want to confirm is my understanding right ?
2、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 ?
My system environment is:
Intel(R) Xeon(R) CPU E5504
If you need more information, I will post them later. Thanks!