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

Comments on porting to other systems.

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
./configure --with-debug=yes --prefix='your installation directory'

# The makefiles generated above needs GNU make (called gmake below)
gmake clean all install init-db

Debugging MySQL

If you have some very specific problem, you can always try to debug MySQL.

Start the mysql server with a trace log in /tmp/mysql.trace. The log file will get very BIG.

mysqld --debug

or you can start it with

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

which only prints information with the most interesting tags.

Comments about RTS threads:

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:

What is the difference between different thread packages?

MySQL is very dependent on the used thread package. So when choosing a good platform for MySQL the thread package is very important.

There are at least three types of thread packages.

In some systems kernel threads are managed by integrating user level threads in the system libraries. In such cases, the thread switching can only be done by the thread library and the kernel isn't really 'thread aware'.

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

Casa de Bender