This bug happens under Windows & Embedded server
Reason is that pthread_self() always returns NULL in this case.
This confuses thr_lock function and it doesn't stop
thread inserting in the write-locked table.

Global problem is that there's no way under Windows to get
unique thread handle for working thread.
Monty made a workaround for server - we store the thread's handle
we get when we create thread in the thread-specific variable.
This doesn't work with the embedded library for we don't control
thread creation there.

I added code that sets CurrentThreadId as the pthread_self
for the embedded library.
It seems to solve problem because it's unique and we don't use
pthread_self as a parameter for thread functions in embedded library. 

into mysql.com:/home/kostja/mysql/mysql-4.0-root

into mysql.com:/home/mysql_src/mysql-4.0

we change THD::system_thread from a 'bool' to a bitmap to be able to
distinguish between delayed-insert threads and slave threads.
- Fix for BUG#1701 "Update from multiple tables" (one line in sql_parse.cc,
plus a new test rpl_multi_update.test). That's just adding an initialization.

into mysql.com:/home/kostja/mysql/mysql-4.0-1790

into mysql.com:/bk/mysql-4.0

into mysql.com:/my/mysql-4.0

move bdb/innodb tests to right places

into mysql.com:/home/dlenev/src/mysql-4.0-tsbug

if we failed to classify integer as datetime 
in Field_datetime::store().
Stylistic clean-ups.

into mysql.com:/home/mysql_src/mysql-4.0

The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the
slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs
it also for check_binlog_magic().
This should fix all recently reported failures of the rpl_max_relay_size test in 4.1 and 5.0
(though the bug exists since 4.0, it showed up first in 5.0).

into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.bugfssl

into mysql.com:/home/psergey/mysql-4.0

   "$1: unbound variable" error when no option was given

into mysql.com:/home/mysql_src/mysql-4.0

into mysql.com:/home/psergey/mysql-4.0

into mysql.com:/home/dlenev/src/mysql-4.0-tsbg

about it". Now numbers representing illegal timestamps are 
converted to 0 value if they are stored as timestamp or 
datetime. This behaviour is consistent with manual and with 
behaviour of string -> timestamp conversion.

 SQL_BIG_RESULT used':
- BIT_AND now returns BIGINT UNSIGNED
- in case there were no matching rows BIT_AND returns 18446744073709551615 
(but not NULL), BIT_OR returns 0 (but not NULL). That's how Monty wants it
and how is described in our docs.

instead of Log_event::Log_event(THD*, ...) when the event is built in the master
to be written in the binlog.
Rand_log_event already used the good constructor, so there really is no reason
for Intvar_log_event to be an exception.
This fixes a test failure of last night (which appeared after I removed a useless
e.server_id=thd->server_id in log.cc; in fact this line was not useless because
it hid the bad constructor).
Replication tests pass, with Valgrind too.

into mysql.com:/home/kostja/mysql/mysql-4.0-1790

into mysql.com:/home/mysql_src/mysql-4.0

which does e.server_id=thd.server_id.

into serg.mylan:/usr/home/serg/Abk/mysql-4.0

It happens that mysql->client_next->client_next=mysql
and mysql_close() goes into infinite loop.
Results vary from simple sigsegv (FreeBSD), to hard system lockup (Linux)
:)

into mysql.com:/my/mysql-4.0

into serg.mylan:/usr/home/serg/Abk/mysql-4.0

into mysql.com:/home/kostja/mysql/mysql-4.0-root

options.rpl_probe} as they are zero-initialized in spawn_init()

no need to set rpl_parse, rpl_probe and rpl_pivot to zero as whole mysql
structure is bzeroed in mysql_init(0) few lines before

into mysql.com:/my/mysql-4.0