A working Posix thread library is needed for the server. On Solaris 2.5 we use SUN PThreads (the native thread support in 2.4 and earlier versions are not good enough) and on Linux we use LinuxThreads by Xavier Leroy Xavier.Leroy@inria.fr.
The hard part of porting to a new UNIX variant without good native thread support is probably to port MIT threads. See `mit-pthreads/README' and Programming POSIX Threads.
The MySQL distribution includes a patched version of Provenzano's Pthreads from MIT (see MIT Pthreads web page). This can be used for some operating systems that does not have posix threads.
It is also possible to use another user level thread package named FSU Pthreads (see FSU pthread home page). This implementation is being used for the SCO port.
See the `thr_lock.c' and `thr_alarm.c' programs in the mysys directory for some tests/examples of these problems
Both the server and the client needs a working C++ compiler (we use gcc and have tried SparcWorks). Other compiler that is known to work is the IRIX cc.
To compile only the client use `./configure --without-server'
There currently no support for only compiling the server. Nor is it likly to be added unless someone has a good reason for it.
If you want/need to change any Makefile or the configure script you must get automake and autoconf. We have used autoconf-2.12 and automake-1.2.
All steps needed to remake everything from the most basic files.
/bin/rm */.deps/*.P /bin/rm -f config.cache aclocal autoheader aclocal automake autoconf ./configure --with-debug=yes --prefix='your installation directory' # The makefiles generated above needs GNU make (called gmake below) gmake clean all install init-db
If you run into problem with a new port, you may have to do some debugging of mysql! 「MySQL のデバッグ」節参照
NOTE: Before you start debugging mysqld, first get the test programs mysys/thr_alarm and mysys/thr_lock to work. This will ensure that your thread installation has even a remotely change to work!
とても特有の問題がある場合は、いつでも MySQL のデバッグを試みることがで
MySQL を configure する必要があります。. You can check if MySQL if compiled with
debugging by doing:
mysqld --help. If the
is listed with the options then you have debugging enabled.
mysqladmin ver also lists the mysqld version as
mysql ... -debug
in this case.
mysql サーバを /tmp/mysql.trace 内にトレースログを取るように起動します。 ログファイルはとても 大きく なります。
When you configure MySQL for debugging you automaticly enable a lot
of extra safety check functions that monitors the health of mysqld. If they
find something 'unexpected' a entry will be written to stderr, which
safe_mysqld directs to the error log! This also means that if you are
having some unexpected problems with
MySQL, the first thing you,
if you are using a source distribution, is to configure
debugging! (The second thing is of course to mail to email@example.com and
ask for help. Please use the mysqlbug script for all bug reports or questions
MySQL version you are using!
多くのシステム（Linux を除く）では、mysqld がクラッシュした場合により多
gdb 内で mysqld を実行することもできます。
shell> gdb libexec/mysqld gdb> run ... back # Do this when mysqld crashes quit
I have tried to use the RTS thread packages with MySQL but stumbled on the following problems:
They use old version of a lot of POSIX calls and it is very tedious to make wrappers for all functions. I am inclined to think that it would be easier to change the thread libraries to the newest POSIX specification.
Some wrappers are already written. Se mysys/my_pthread.c for more info.
At least the following should be changed:
pthread_get_specific should use on argument. sigwait should take two arguments. A lot of functions (at least pthread_cond_wait, pthread_cond_timedwait) should return the error code on error. Now they return -1 and set errno.
Another problem is that user level threads uses the ALRM signal and this aborts a lot of functions (read, write, open...). MySQL should do a retry on interrupt on all of these but it not that easy to verify it.
The biggest unsolved problem is the following:
To get thread_level alarms I changed mysys/thr_alarm.c to wait between alarms with pthread_cond_timedwait() but this aborts with error EINTR. I tried to debug the thread library why this happens but couldn't find any easy solution.
If someone wants to try MySQL with RTS threads I suggest the following:
Main thread: 1 Tread 0 (5) started Thread: 5 Waiting process_alarm Tread 1 (6) started Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Sleeped for 1 (1) sec Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Sleeped for 2 (2) sec Thread: 6 Simulation of no alarm needed Thread: 6 Sleeped for 0 (3) sec Thread: 6 Waiting process_alarm process_alarm thread_alarm Thread: 6 Sleeped for 4 (4) sec Thread: 6 Waiting process_alarm thread_alarm Thread: 5 Sleeped for 10 (10) sec Thread: 5 Waiting process_alarm process_alarm thread_alarm Thread: 6 Sleeped for 5 (5) sec Thread: 6 Waiting process_alarm process_alarm ... thread_alarm Thread: 5 Sleeped for 0 (1) sec end
MySQL は使用されるスレッドパッケージに非常に依存しています。そ のため、MySQL に良いプラットフォームを選択する時には、スレッド パッケージが非常に重要です。
いくつかのシステムでは、カーネルスレッドは、システムライブラリ内で、ユー ザレベルスレッドの統合によって管理されます。この場合、スレッド切替えはス レッドライブラリによってだけ行なわれ、カーネルは実際には 'thread aware' ではありません。
Go to the first, previous, next, last section, table of contents.