APC thread per connection impl
To have a guaranteed wakeup with no lost signal, the folowing approaches
are applied on different platforms:
* Linux/FreeBSD:
This applies to any platform with _GNU_SOURCE defined.
1. set a signal mask to ignore the signal (namely, SIGUSR1. It is better
not to interfer with the signals that can be used by OS)
2. call ppoll instead of poll, that applies the signal mask atomically
with polling.
3. hopefully, if the signal is received before the ppoll call
(i.e. masked out) will be still set to pending, so the next ppoll call
(as well as any unmasking) will force it to be handled. We will receive
EINTR and the read will be retried.
* Solaris, other POSIX
There is no ppoll function on Solaris, but it has differently handled
opened files limitation, which allows to freely open new file descriptors
as needed.
Here we will use the self-pipe trick to wake up:
1. A thread-local pipe is created. Its read end will be additionally used
by poll.
2. A signal handler will write to this pipe to wake up from poll.
Linux is not safe for using this method, because its file limits are rather
low, especially the default ones.
Solaris has the per-process restriction rather than per-user:
https://support.oracle.com/knowledge/Sun%20Microsystems/1005979_1.html
> A process can have up to rlim_fd_cur file descriptors and can increase
> the number up to rlim_fd_max.
The latter is 1024 on Solaris 7 by default.
We can't say about other POSIX'es limitations, but it is assumed they have
no ppoll function.
pselect is not assumed because of the silly limitations.
So the only way for them can be self-piping.
* Windows
Self-pipe trick is used as well, but instead of poll, select is used,
and QueueUserAPC is used instead of signals.
Caveats:
* It is possible that the connection will hang on write for long.
The requestor should wait until the write ends, or fail with timeout.
* The connection can hang in other commands for long, for example, on
sleep().
We generally can't assume it is safe to handle the apc during both of these
cases, but maybe some safe zones can be marked. Anyway it is considered to
be out of the scope of this task.
APC API: Fix race condition cond_timedwait() vs mutex_destroy via LOCK_thd_kill
Basically, when we begin waiting on condition, the mutex is unlocked,
so the protection inside ~THD
mysql_mutex_lock(&LOCK_thd_kill);
mysql_mutex_unlock(&LOCK_thd_kill);
doesn't work. The mutex is freely acquired and it is skipped.
Then mysql_mutex_destroy can be called.
Meanwhile, another thread can receive the signal and acquire the mutex
back, which is UB, since it was already destroyed.
In particalar, safe_cond_timedwait tries to update some statistics on mutex
that were freed by safe_mutex_destroy, as well as mp->global, which is
tried to acquire.
