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
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

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:

• 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 is 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 one the right track. Here follows an successful run on Solaris:

  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
  

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.

• User threads in a single process. Thread switching is managed with alarms and the threads library manages all not thread- safe functions with locks. Read, write and select are usually managed with a thread-specific select that switches to another thread if the running threads have to wait for data. If the user thread packages are integrated in the standard libs (FreeBSD and BSDI threads) the thread package requires less overhead than thread packages that have to map all unsafe calls (MIT-threads, FSU-threads and RTS threads). In some environments (for example SCO), all system calls are thread- safe so the mapping can be done very easily (FSU-threads on SCO). Downside: All mapped calls take a little time and it's quite tricky to be able to handle all situations. There are usually also some system calls that are not handled by the thread package (like MIT-threads and sockets). Thread scheduling isn't always optimal.
• User threads in separate processes. Thread switching is done by the kernel and all data is shared between threads. The thread package manages the standard thread calls to allow sharing data between threads. Linuxthreads is using this method. Downside: Lots of processes. Thread creating is slow. If one thread dies the rest are usually left hanging and one has to kill them all before restarting. Thread switching is somewhat expensive.
• Kernel threads. Thread switching is handled by the thread library or the kernel and is very fast. Everything is done in one process but 'ps' may on some systems show the different threads. If one thread aborts the whole process aborts. Most system calls are threadsafe and should require very little overhead. Solaris, HP/UX, AIX and OSF1 has kernel threads.

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.