1) add support for joinable threads to Thread class;
2) move checking of thread model to Manager from mysqlmanager.cc,
because it is needed only for IM-main process.

into  bodhi.local:/opt/local/work/m51lamp

Alik's patch for BUG#22306: STOP INSTANCE can not be applied for 
instances in Crashed, Failed and Abandoned" to ease review process.
Evaluate global variable linuxthreads before starting threads to avoid
a race.

into  bodhi.local:/opt/local/work/m51lamp

spawned threads with a reusable class Thread.

This is the second idea implemented in the Alik's patch for
BUG#22306: STOP INSTANCE can not be applied for instances in Crashed,
Failed and Abandoned.
Commiting separately to ease review process. 

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug23383

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug23383

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23383

mysql_stmt_affected_rows()

The problem was that affected_rows for prepared statement wasn't updated
in the client library on the error.  The solution is to always update
affected_rows, which will be equal to -1 on the error.

BUG#22306: STOP INSTANCE can not be applied for instances in Crashed,
Failed and Abandoned

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-22684

Before this change, the functions BENCHMARK, ENCODE, DECODE and FORMAT could
only accept a constant for some parameters.

After this change, this restriction has been removed. An implication is that
these functions can also be used in prepared statements.

The change consist of changing the following classes:
- Item_func_benchmark
- Item_func_encode
- Item_func_decode
- Item_func_format
to:
- only accept Item* in the constructor,
- and evaluate arguments during calls to val_xxx()
which fits the general design of all the other functions.

The 'TODO' items identified in item_create.cc during the work done for
Bug 21114 are addressed by this fix, as a natural consequence of aligning
the design.

In the 'func_str' test, a single very long test line involving an explain
extended select with many functions has been rewritten into multiple
separate tests, to improve maintainability.
The result of explain extended select decode(encode(...)) has changed,
since the encode and decode functions now print all their parameters.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug17047

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17047

The problem was that some functions (namely IN() starting with 4.1, and
CHAR() starting with 5.0) were returning NULL in certain conditions,
while they didn't set their maybe_null flag.  Because of that there could
be some problems with 'IS NULL' check, and statements that depend on the
function value domain, like CREATE TABLE t1 SELECT 1 IN (2, NULL);.

The fix is to set maybe_null correctly.

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-18239

Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)

This change contains a fix to report warnings or errors, and multiple tests
cases.

Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.

I) Native / User Defined Function

Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.

II) Native / Stored Function

Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.

III) User Defined Function / Stored Function

Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the  behavior is unchanged, and is now covered by test cases.

Note that the code change in this patch depends on the fix for Bug 21114.

trigger which uses stored function invoked from different connections"
into 5.1.

into  mockturtle.local:/home/dlenev/src/mysql-5.1-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg23651

stored function invoked from different connections".

Invocation of trigger which was using stored function from different
connections caused server crashes (for non-debug server this happened
in highly concurrent environment, but debug server failed on assertion
in relatively simple scenario).

Item_func_sp was not safe to use in triggers (in other words for
re-execution from different threads) as artificial TABLE object
pointed by Item_func_sp::dummy_table referenced incorrect THD
object. To fix the problem we force re-initialization of this
object for each re-execution of statement.

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  mysql.com:/Users/kent/mysql/bk/mysql-5.1

into  mysql.com:/Users/kent/mysql/bk/mysql-5.0

  Test for base directory when a RPM install corrected

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M51/push-5.1