Go to the first, previous, next, last section, table of contents.

# G 他のシステムへの移植について

移植先のシステムには POSIX 仕様のスレッドライブラリが必要となります。 我々は Solaris 2.5 では Sun PThreads (2.4以前でサポートされていたネイティブthreadは良くなかった)を、 Linux では Xavier Leroy, Xavier.Leroy@inria.fr による LinuxThreads を使っています。

良いネイティブスレッドを持たない新種の Unix に移植する場合、 多分もっとも大変な作業は MIT-pthreads を導入する部分です。 ``mit-pthreads/README'` と Programming POSIX Threadsをご覧下さい。

MySQL の配布ファイルには MIT の Provenzano's Pthreads パッチ済みバージョン ( MIT Pthreads web pageをご覧下さい。) が含まれています。 これは POSIX 仕様の Threads を持たない OS に使用可能と思われます。

もう1つのユーザレベル thread パッケージ、FSU Pthreads も使用可能と思われます ( FSU Pthreads home pageをご覧下さい。)。 これはSCOへの移植に使用可能です。

そういった問題に関するテストやサンプルのプログラムを作成する場合には ``mysys'` ディレクトリの ``thr_lock.c'` と ``thr_alarm.c'` 等のプログラムをご覧下さい。

移植にはサーバー、クライアントともに C++ コンパイラを必要とします (ちなみに我々は`gcc`を使っています。SparcWorks(C++)は試しました。)。 Irix `cc`も使用できることが確かめられています。

クライアントしか必要無い場合は`./configure --without-server`とコンパイルしてください。

サーバのみコンパイルする方法は今のところありません。必要性が生じるまでは今のままです。

``Makefile'` か コンフィギャスクリプトに何らかの変更をする必要が生じたなら Automake と Autoconf を使わなくてはいけません。 ちなみに、我々は `automake-1.2` と `autoconf-2.12` を使っています。

変更の手順は全て基本的なファイルからやり直す必要があります。

    /bin/rm */.deps/*.P
    /bin/rm -f config.cache
    aclocal
    autoheader
    aclocal
    automake
    autoconf
    ./configure --with-debug=full --prefix='your installation directory'

    # 上記手順によって生成されるmakefileファイル群はGNU make 3.75以上
    # (以下、gmakeと記述します。)を必要とします。
    gmake clean all install init-db

新しい移植で問題が発生すればデバッグの必要が生じる場合もあります。

「G.1 MySQL server のデバッグ」節参照.

NOTE: `mysqld`のデバッグを開始する前に`mysys/thr_alarm`と`mysys/thr_clock`が動くかどうかチェックしてください。これにより貴方のインストールしたthread環境の動作可能性が多少でもあるのかどうかを確かめることができます。

## G.1 MySQL server のデバッグ

もしあなたが MySQL のとても新しいある機能を使っている場合、 `--skip-new` (これは全く新しい、潜在的に危険な機能を無効にします) または `--safe-mode` (これは問題を生じさせるかもしれない多くの最適化を無効にします) オプションで `mysqld` を実行させることができます。 「A.4.1 What To Do If MySQL Keeps Crashing」節参照.

もし `mysqld` が起動しないようなら、 `my.cnf` が無いかチェックしてください。 `my.cnf` の引数は `mysqld --print-defaults` でチェックできます。 また `mysqld --no-defaults ...` で起動することにより、 `my.cnf` を無視することが可能です。

もし `mysqld` が CPU や メモリー を食い始めたり、``ハング'' したりするなら、 `mysqladmin processlist status` を使用して誰かが多くの時間のかかる クエリを実行しているか確かめることが出来ます。 パフォーマンスの問題や新しいクライアントが接続できないときの問題と もしあなたが考えるなら、 いくつかのウインドウで `mysqladmin -i10 processlist status` を 実行するのはよい考えでしょう。

`mysqladmin debug` コマンドは使用中のロック、使用しているメモり、 クエリの使用の情報を、mysql ログファイルにいくつかダンプします これはいくつかの問題解決に役立ちます。 このコマンドは、 MySQL を デバッグ可能でコンパイルしていなくても、いくつかの役立つ情報も提供します。

いくつかのテーブルでだんだん遅くなる問題であるなら、 `OPTIMIZE TABLE` か `myisamchk` でテーブルを修復し、最適化を試みるべきです。 遅いクエリは、 `EXPLAIN` でもチェックできます。 「4 MySQL Database Administration」節参照. You should also check the slow queries with `EXPLAIN`.

このマニュアルの OS 固有の問題 の節も読むべきです。 「2.6 Operating System Specific Notes」節参照.

### G.1.1 Compiling MYSQL for debugging.

もしあるとても特殊な問題があれば、あなたは、いつも MySQL を デバッグするよう試みることができます。 これを行うには、 MySQL を `--with-debug` オプションか `--with-debug=full` オプション付きで configure しなくてはなりません。 MySQL がデバッギングを有効にしてコンパイルされているかを 知るには、 `mysqld --help` とします。 もし `--debug` フラグが リストされていればデバッグが有効です。 `mysqladmin ver` も `mysqld` のバージョンをリストできます。 この場合は `mysql ... --debug` と、バージョン番号に表示されるでしょう。

gcc か egcs の場合、推奨する configure のラインは：

    CC=gcc CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-debug --with-extra-charsets=complex

This will avoid problems with the `libstdc++` library and with C++ exceptions (many compilers have problems with C++ exceptions in threaded code) and compile a MySQL version with support for all character sets.

If you suspect a memory overrun error, you can configure MySQL with `--with-debug=full`, which will install a memory allocation (`SAFEMALLOC`) checker. Running with `SAFEMALLOC` is however quite slow, so if you get performance problems you should start `mysqld` with the `--skip-safemalloc` option. This will disable the memory overrun checks for each call to `malloc` and `free`.

If `mysqld` stops crashing when you compile it with `--with-debug`, you have probably found a compiler bug or a timing bug within MySQL. In this case you can try to add `-g` to the `CFLAGS` and `CXXFLAGS` variables above and not use `--with-debug`. If `mysqld` now dies, you can at least attach to it with `gdb` or use `gdb` on the core file to find out what happened.

MySQL をデバッグで configure すると、自動で多くの安全な検査関数が enable になります。 これは `mysqld` の状態をモニターできます。 もしそれら関数がなにか ``予期せぬこと'' を発見したら、それらを `stderr` に書き出します。 これは `safe_mysqld` が受け取って error ログに 書き出します！ このことはどういうことかというと、 MySQL に予期せぬことが 起きた場合、まず最初にすべきことは、 MySQL をデバッグ有効にして configure することです！ （次に、もちろん、 mysql@lists.mysql.com に メールを送り、help を聞くことです。 全てのバグレポート、MySQL のバージョンに 関連する質問は、 `mysqlbug` スクリプトを使用してください！）

In the Windows MySQL distribution, `mysqld.exe` is by default compiled with support for trace files.

### G.1.2 Creating trace files

If the `mysqld` server doesn't start or if you can cause the `mysqld` server to crash quickly, you can try to create a trace file to find the problem.

To do this you have to have a `mysqld` that is compiled for debugging. You can check this by executing `mysqld -V`. If the version number ends with `-debug`, it's compiled with support for trace files.

Start the `mysqld` server with a trace log in ``/tmp/mysqld.trace'` (or ``C:\mysqld.trace'` on Windows):

`mysqld --debug`

On Windows you should also use the `--standalone` flag to not start `mysqld` as a service:

In a DOS window do:

    mysqld --debug --standalone

After this you can use the `mysql.exe` command line tool in a second DOS window to reproduce the problem. You can take down the above `mysqld` server with `mysqladmin shutdown`.

Note that the trace file will get very BIG! If you want to have a smaller trace file, you can use something like:

`mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace`

which only prints information with the most interesting tags in ``/tmp/mysqld.trace'`.

If you make a bug report about this, please only send the lines from the trace file to the appropriate mailing list where something seems to go wrong! If you can't locate the wrong place, you can ftp the trace file, together with a full bug report, to ftp://support.mysql.com/pub/mysql/secret so that a MySQL developer can take a look a this.

The trace file is made with the DBUG package by Fred Fish. 「G.3 The DBUG package.」節参照.

### G.1.3 Debugging mysqld under gdb

ほとんどのシステムでは、もし `mysqld` がクラッシュするなら、 `gdb` から `mysqld` を起動させて多くの情報を得ることが可能です。

Linux 上でのいくつかの `gdb` バージョンでは、 `mysqld` スレッドのデバッグを可能にする場合、 `run --one-thread` を使用しなくてはなりません。 この場合、一度にただ一つのactiveなスレッドだけを持つことになります。

When running `mysqld` under gdb, you should disable the stack trace with `--skip-stack-trace` to be able to catch segfaults within gdb.

It's very hard to debug MySQL under `gdb` if you do a lot of new connections the whole time as `gdb` doesn't free the memory for old threads. You can avoid this problem by starting `mysqld` with `-O thread_cache_size= 'max_connections +1'`. In most cases just using `-O thread_cache_size=5'` will help a lot!

If you want to get a core dump on Linux if `mysqld` dies with a SIGSEGV signal, you can start `mysqld` with the `--core-file` option. This core file can be used to make a backtrace that may help you find out why `mysqld` died:

    shell> gdb mysqld core
    gdb>   backtrace full
    gdb>   exit

「A.4.1 What To Do If MySQL Keeps Crashing」節参照.

もし Linux 上で gdb 4.17.x を使用しているなら、 ``.gdb'` ファイルを いかにしたがって、カレントのディレクトリーにインストールすべきです：

    set print sevenbit off
    handle SIGUSR1 nostop noprint
    handle SIGUSR2 nostop noprint
    handle SIGWAITING nostop noprint
    handle SIGLWP nostop noprint
    handle SIGPIPE nostop
    handle SIGALRM nostop
    handle SIGHUP nostop
    handle SIGTERM nostop noprint

If you have problems debugging threads with gdb, you should download gdb 5.x and try this instead. The new gdb version has very improved thread handling!

以下は mysqld のデバッグ例です：

    shell> gdb /usr/local/libexec/mysqld
    gdb> run
    ...
    backtrace full # mysqld がクラッシュした際、これを行います

上記の出力を、 `mysqlbug` で作成したメールに含み、 そして `mysql@lists.mysql.com`. に送ってください。

もし `mysqld` がハングするなら、 `strace` や `/usr/proc/bin/pstack` のような システムツールを使用して `mysqld` がどこでハングしているか 調べることができます。

    strace /tmp/log libexec/mysqld

もし Perl `DBI` を使用しているなら、 `trace` メソッド、あるいは`DBI_TRACE` 環境変数で デバッグ情報を有効にできます。 「8.2.2 The `DBI` Interface」節参照.

### G.1.4 Using a stack trace

On some operating systems, the error log will contain a stack trace if `mysqld` dies unexpectedly. You can use this to find out where (and maybe why) `mysqld` died. 「4.9.1 The Error Log」節参照. To get a stack trace, you should NOT compile `mysqld` with the `-fomit-frame-pointer` option to gcc. 「G.1.1 Compiling MYSQL for debugging.」節参照.

If the error file contains something like the following:

    mysqld got signal 11;
    The manual section 'Debugging a MySQL server' tells you how to use a
    stack trace and/or the core file to produce a readable backtrace that may
    help in finding out why mysqld died
    Attemping backtrace. You can use the following information to find out
    where mysqld died.  If you see no messages after this, something went
    terribly wrong
    stack range sanity check, ok, backtrace follows
    0x40077552
    0x81281a0
    0x8128f47
    0x8127be0
    0x8127995
    0x8104947
    0x80ff28f
    0x810131b
    0x80ee4bc
    0x80c3c91
    0x80c6b43
    0x80c1fd9
    0x80c1686

you can find where `mysqld` died by doing the following:

1. Copy the above numbers to a file, for example ``mysqld.stack'`.
2. Make a symbol file for the `mysqld` server:

       nm -n libexec/mysqld > /tmp/mysqld.sym

   Note that many MySQL binary distributions comes with the above file, named `mysqld.sym.gz`. In this case you must unpack this by doing:

       gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym

3. Execute `resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack`. This will print out where `mysqld` died. If this doesn't help you find out why `mysqld` died, you should make a bug report and include the output from the above commend with the bug report. Note however that in most cases it will not help us to just have a stack trace to find the reason for the problem. To be able to locate the bug or provide a workaround, we would in most cases need to know the query that killed `mysqld` and preferable a test case so that we can repeat the problem! 「1.2.22.3 バグや問題を報告する方法」節参照.

### G.1.5 Using log files to find cause of errors in mysqld

Note that before starting `mysqld` with `--log` you should check all your tables with `myisamchk`. 「4 MySQL Database Administration」節参照.

もし `mysqld` が死んだりハングしたりするなら、 `mysqld` を `--log` で起動すべきです。 再び `mysqld` が死んだら、 あなたはログファイル中の、 `mysqld` を kill するクエリをチェックします。

If you are using `--log` without a file name, the log is stored in the database directory as 'hostname'.log In most cases it's the last query in the log file that killed `mysqld`, but if possible you should verify this by restarting `mysqld` and executing the found query from the `mysql` command line tools. If this works, you should also test all complicated queries that didn't complete.

`mysqld` が適切にインデックスを使用するのに時間がとてもかかる全ての `SELECT` 文を `EXPLAIN` で実行することを試みます。 「5.2.1 `EXPLAIN` 構文 (`SELECT`についての情報を得る)」節参照.

You can find the queries that take a long time to execute by starting `mysqld` with `--log-slow-queries`. 「4.9.5 The Slow Query Log」節参照.

もしエラーログファイル(通常 ``hostname.err'` という名前)中に `mysqld restarted` という文があるなら、 `mysqld` を失敗させるクエリを見つけます。 もしこれが起きるなら、`myisamchk` ( 「4 MySQL Database Administration」節参照) で 全てのテーブルをチェックし、MySQL ログファイルにあるそのクエリをテストすべきです。 もしそのようなクエリをみつけたなら、まず最初に最新の MySQL にアップグレード してみてください。 もしそれでもだめで、かつ `mysql` メーリングリストの アーカイブにもなにも見つけることが出来なかったなら、 mysql@lists.mysql.com に バグレポートを出すべきです。 メーリングリストのアーカイブへのリンクは MySQL documentation page.

If you have started `mysqld` with `--with-myisam-recover`, MySQL will automatically check and try to repair `MyISAM` tables if they are marked as 'not closed properly' or 'crashed'. If this happens, MySQL will write an entry in the `hostname.err` file `'Warning: Checking table ...'` which is followed by `Warning: Repairing table` if the table needs to be repaired. If you get a lot of these errors, without `mysqld` having died unexpectedly just before, then something is wrong and needs to be investigated further. 「4.1.1 mysqld コマンド行オプション」節参照.

It's of course not a good sign if `mysqld` did died unexpectedly, but in this case one shouldn't investigate the `Checking table...` messages but instead try to find out why `mysqld` died.

### G.1.6 Making a test case when you experience table corruption

もし不正なテーブルをえたり、 `mysqld` が常にいくつかの update コマンドで 失敗するなら、以下のようにしてこのバグの再現をテストします：

- Take down the MySQL daemon (with `mysqladmin shutdown`).
- Make a backup of the tables (to guard against the very unlikely case that the repair will do something bad).
- `myisamchk -s database/*.MYI` で全テーブルをチェック. `myisamchk -r database/table.MYI` で悪いテーブルを修正。
- Make a second backup of the tables.
- Remove (or move away) any old log files from the MySQL data directory if you need more space.
- Start `mysqld` with `--log-bin`. 「4.9.4 The Binary Update Log」節参照. If you want to find a query that crashes `mysqld`, you should use `--log --log-bin`.
- 壊れたテーブルを得た時、`mysqld server` を停止。
- バックアップをリストア
- `mysqld` server を `--log-bin` なしで 起動。
- Re-execute the commands with `mysqlbinlog update-log-file | mysql`. The update log is saved in the MySQL database directory with the name `hostname-bin.#`.
- If the tables are corrupted again or you can get `mysqld` to die with the above command, you have found reproducible bug that should be easy to fix! FTP the tables and the binary log to ftp://support.mysql.com/pub/mysql/secret and send a mail to bugs@lists.mysql.com or (if you are a support customer) to support@mysql.com about the problem and the MySQL team will fix it as soon as possible.

You can also use the script `mysql_find_rows` to just execute some of the update statements if you want to narrow down the problem.

## G.2 Debugging a MySQL client

To be able to debug a MySQL client with the integrated debug package, you should configure MySQL with `--with-debug`. 「2.3.3 典型的な `configure` オプション」節参照.

Before running a client, you should set the `MYSQL_DEBUG` environment variable:

    shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace
    shell> export MYSQL_DEBUG

This causes clients to generate a trace file in ``/tmp/client.trace'`.

If you have problems with your own client code, you should attempt to connect to the server and run your query using a client that is known to work. Do this by running `mysql` in debugging mode (assuming you have compiled MySQL with debugging on):

    shell> mysql --debug=d:t:O,/tmp/client.trace

This will provide useful information in case you mail a bug report. 「1.2.22.3 バグや問題を報告する方法」節参照.

If your client crashes at some 'legal' looking code, you should check that your ``mysql.h'` include file matches your mysql library file. A very common mistake is to use an old ``mysql.h'` file from an old MySQL installation with new MySQL library.

## G.3 The DBUG package.

The MySQL server and most MySQL clients are compiled with the DBUG package originally made by Fred Fish. When one has configured MySQL for debugging, this package makes it possible to get a trace file of what the program is debugging. 「G.1.2 Creating trace files」節参照.

One uses the debug package by invoking the program with the `--debug="..."` or the `-#...` option.

Most MySQL programs has a default debug string that will be used if you don't specify an option to `--debug`. The default trace file is usually `/tmp/programname.trace` on Unix and `\programname.trace` on Windows.

The debug control string is a sequence of colon separated fields as follows:

    <field_1>:<field_2>:...:<field_N>

Each field consists of a mandatory flag character followed by an optional "," and comma-separated list of modifiers:

    flag[,modifier,modifier,...,modifier]

The currently recognized flag characters are:

d | Enable output from DBUG_<N> macros for the current state. May be followed by a list of keywords which selects output only for the DBUG macros with that keyword. An empty list of keywords implies output for all macros.
D | Delay after each debugger output line. The argument is the number of tenths of seconds to delay, subject to machine capabilities. That is, `-#D,20` is delay two seconds.
f | Limit debugging and/or tracing, and profiling to the list of named functions. Note that a null list will disable all functions. The appropriate "d" or "t" flags must still be given, this flag only limits their actions if they are enabled.
F | Identify the source file name for each line of debug or trace output.
i | Identify the process with the pid or thread id for each line of debug or trace output.
g | Enable profiling. Create a file called 'dbugmon.out' containing information that can be used to profile the program. May be followed by a list of keywords that select profiling only for the functions in that list. A null list implies that all functions are considered.
L | Identify the source file line number for each line of debug or trace output.
n | Print the current function nesting depth for each line of debug or trace output.
N | Number each line of dbug output.
o | Redirect the debugger output stream to the specified file. The default output is stderr.
O | As `O` but the file is really flushed between each write. When needed the file is closed and reopened between each write.
p | Limit debugger actions to specified processes. A process must be identified with the DBUG_PROCESS macro and match one in the list for debugger actions to occur.
P | Print the current process name for each line of debug or trace output.
r | When pushing a new state, do not inherit the previous state's function nesting level. Useful when the output is to start at the left margin.
S | Do function _sanity(_file_,_line_) at each debugged function until _sanity() returns something that differs from 0. (Mostly used with safemalloc to find memory leaks)
t | Enable function call/exit trace lines. May be followed by a list (containing only one modifier) giving a numeric maximum trace level, beyond which no output will occur for either debugging or tracing macros. The default is a compile time option.

Some examples of debug control strings which might appear on a shell command line (the "-#" is typically used to introduce a control string to an application program) are:

    -#d:t
    -#d:f,main,subr1:F:L:t,20
    -#d,input,output,files:n
    -#d:t:i:O,\\mysqld.trace

In MySQL, common tags to print (with the `d` option) are: `enter`,`exit`,`error`,`warning`,`info` and `loop`.

## G.4 Locking methods

Currently MySQL only supports table locking for `ISAM`/`MyISAM` and `HEAP` tables and page level locking for `BDB` tables. 「5.3.1 MySQL はどのようにテーブルをロックするか」節参照. With `MyISAM` tables one can freely mix `INSERT` and `SELECT` without locks (`Versioning`).

Starting in version 3.23.33, you can analyze the table lock contention on your system by checking `Table_locks_waited` and `Table_locks_immediate` environment variables.

Some database users claim that MySQL cannot support near the number of concurrent users because it lacks row-level locking. This may be true for some specific applications, but is not generally true. As always this depends totally on what the application does and what is the access/update pattern of the data.

Pros for row locking:

- Fewer lock conflicts when accessing different rows in many threads.
- Less changes for rollbacks.
- Makes it possible to lock a single row a long time.

Cons:

- Takes more memory than page level or table locks.
- Is slower than page level or table locks when used one a big part of the table, because one has to do many more locks.
- Is definitely much worse than other locks if you do often do `GROUP BY` on a large part of the data or if one has to often scan the whole table.
- With higher level locks one can also more easily support locks of different types to tune the application as the lock overhead is less notable as for row level locks.

Table locks are superior to page level / row level locks in the following cases:

- Mostly reads
- Read and updates on strict keys; This is where one updates or deletes a row that can be fetched with one key read:

      UPDATE table_name SET column=value WHERE unique_key#
      DELETE FROM table_name WHERE unique_key=#

- `SELECT` combined with `INSERT` (and very few `UPDATE`'s and `DELETE`'s.
- Many scans / `GROUP BY` on the whole table without any writers.

Other options than row / page level locking:

Versioning (like we use in MySQL for concurrent inserts) where you can have one writer at the same time as many readers. This means that the database/table supports different views for the data depending on when one started to access it. Other names for this are time travel, copy on write or copy on demand.

Copy on demand is in many case much better than page or row level locking; The worst case does, however, use much more memory than when using normal locks.

Instead of using row level locks one can use application level locks. (Like get_lock/release_lock in MySQL). This works of course only in well-behaved applications.

In many cases one can do an educated guess which locking type is best for the application but generally it's very hard to say that a given lock type is better than another; Everything depends on the application and different part of the application may require different lock types.

Here are some tips about locking in MySQL:

On web application most applications do lots of selects, very few deletes, updates mainly on keys and inserts in some specific tables. The base MySQL setup is VERY tuned for this.

Concurrent users is not a problem if one doesn't mix updates and selects that needs to examine many rows in the same table.

If one mixes inserts and deletes on the same table then `INSERT DELAYED` may be of great help.

One can also use `LOCK TABLES` to speed up things (many updates within a single lock is much faster than updates without locks). Splitting thing to different tables will also helps.

If you get speed problems with the table locks in MySQL, you may be able to solve these to convert some of your tables to `BDB` tables. 「7.5 BDB or Berkeley_DB Tables」節参照.

The optimization section in the manual covers a lot of different aspects of how to tune ones application. 「5.2.11 最適化に関するその他の助言」節参照.

## G.5 Comments about RTS threads

I have tried to use the RTS thread packages with MySQL but stumbled on the following problems:

They use an 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. See ``mysys/my_pthread.c'` for more info.

At least the following should be changed:

`pthread_get_specific` should use one 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 use 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 is 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 as to why this happens, but couldn't find any easy solution.

If someone wants to try MySQL with RTS threads I suggest the following:

- Change functions MySQL uses from the thread library to POSIX. This shouldn't take that long.
- Compile all libraries with the `-DHAVE_rts_threads`.
- Compile `thr_alarm`.
- If there are some small differences in the implementation, they may be fixed by changing ``my_pthread.h'` and ``my_pthread.c'`.
- Run `thr_alarm`. If it runs without any ``warning'', ``error'' or aborted messages, you are on the right track. Here is a successful run on Solaris:

      Main thread: 1
      Thread 0 (5) started
      Thread: 5  Waiting
      process_alarm
      Thread 1 (6) started
      Thread: 6  Waiting
      process_alarm
      process_alarm
      thread_alarm
      Thread: 6  Slept for 1 (1) sec
      Thread: 6  Waiting
      process_alarm
      process_alarm
      thread_alarm
      Thread: 6  Slept for 2 (2) sec
      Thread: 6  Simulation of no alarm needed
      Thread: 6  Slept for 0 (3) sec
      Thread: 6  Waiting
      process_alarm
      process_alarm
      thread_alarm
      Thread: 6  Slept for 4 (4) sec
      Thread: 6  Waiting
      process_alarm
      thread_alarm
      Thread: 5  Slept for 10 (10) sec
      Thread: 5  Waiting
      process_alarm
      process_alarm
      thread_alarm
      Thread: 6  Slept for 5 (5) sec
      Thread: 6  Waiting
      process_alarm
      process_alarm

      ...
      thread_alarm
      Thread: 5  Slept for 0 (1) sec
      end

## G.6 スレッドパッケージ間の違いは何？

MySQL は使用されるスレッドパッケージに非常に依存しています。 そのため、MySQL に良いプラットフォームを選択する時には、 スレッドパッケージが非常に重要です。

少なくとも3つのタイプのスレッドパッケージがあります：

- シングルプロセス内のユーザスレッド。 スレッド切替えはアラームで管理され、 スレッドライブラリはロックを伴う非スレッド安全関数のすべてを管理します。 動作中スレッドがデータを待つ必要がある場合、read, write そして select は、 通常、他のスレッドに切替えるスレッド固有の select で管理されます。 もしユーザ・スレッドパッケージが標準ライブラリ (FreeBSD と BSDI スレッド) に 統合されているなら、スレッドパッケージのオーバーヘッドは、全ての非安全コールを マップしなければならないスレッドパッケージ(MIT-スレッド, FSU-スレッド, RTS スレ ッド) よりも少なくなります。 他の環境(例えば SCO)では、全てのシステムコールはスレッド安全なので、 マッピングはとても簡単に行なわれます(SCO 上の FSU-スレッド)。 Downside: 全てのマップされるコールは少し時間がかかり、全ての状況を 処理可能にすることは、とても困難です。 通常、スレッドパッケージによって処理できないシステムコールがいくつかあります (MIT-スレッドとソケットのように)。 スレッドスケジューリングは常に最 適というわけではあ りません。
- 別プロセスのユーザスレッド。 スレッド切替えはカーネルによって行なわれ、全てのデータはスレッド間で共有されます。 スレッドパッケージは、スレッ ド間のデータ共有を許可するために標準スレッドコール を管理します。 LinuxThreads はこの方法を使用しています。 Downside: 多くのプロセス。スレッド生成は遅いです。 もし一つのスレッドが死ぬと、残りは通常ハングして残り、再起動前に それら全て を kill する必要があります。スレッド切替えはいくらか高価(expensive)です。
- カーネルスレッド。 スレッド切替えはスレッドライブラリかカーネルによって処理され、 とても速いです。 全ては一つのプロセス内で行なわれますが、 いくつかのシステムでは、`ps` が異なったスレッドを示します。 もし一つのスレッドがアボートした場合、プロセス全体がアボートします。 多くのシステムコールはスレッド安全で、オーバーヘッドはとても少ないです。 Solaris, HP-UX, AIX そして OSF1 がカーネルスレッドを持っています。

いくつかのシステムでは、カーネルスレッドは、システムライブラリ内で、 ユーザレベルスレッドの統合によって管理されます。 この場合、スレッド切替えはスレッドライブラリによってだけ行なわれ、 カーネルは実際には 'thread aware' ではありません。

Go to the first, previous, next, last section, table of contents.