The previous two patches for this bug worked together so that
no permanent table was memory mapped. The first patch tried to
avoid mapping while a table is in use. It allowed mapping only
if there was exactly one lock on the table, assuming that the
calling thread owned it. During mi_open(), a different call to
memory mapping was coded, which did not have this limitation.

The second patch tried to remove the code duplication and just
called mi_extra() from mi_open() an thus inherited the limitation.
But on open, a thread does not have a lock on the table...

A possible solution would be to check for zero or one lock.
But since I learned that it is safe to memory map a file while
normal file I/O is done on it, I removed the restriction altogether
and allow to memory map while a table is in use.

No test case. I do not see a chance to verify with the test suite
which kind of I/O is used on a table.

into  chilla.local:/home/mydev/mysql-5.1-bug25460

Decreased code duplication by calling memory mapping
function through mi_extra().

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.0-axmrg

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

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.1-axmrg

into  chilla.local:/home/mydev/mysql-5.0-axmrg

into  chilla.local:/home/mydev/mysql-5.0-axmrg

into  olga.mysql.com:/home/igor/mysql-5.1-opt

into  olga.mysql.com:/home/igor/mysql-5.1-opt

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt

into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug25807/my51-bug25807

Showstopper and regression against 5.0.24.

Previously, we ignored seek() errors (see Bug#22828) and let seek()s
against pipes fail.  Now, since we check that a seek didn't fail,
and return without reading, this bug popped up.

This restores the behavior for file-ish objects that could never be 
seek()ed.

into  olga.mysql.com:/home/igor/mysql-5.1-opt

into  bk-internal.mysql.com:/data0/bk/mysql-4.1-opt

into  chilla.local:/home/mydev/mysql-5.1-bug25460

into  chilla.local:/home/mydev/mysql-5.1-bug25460-old

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint

into  zippy.cornsilk.net:/home/cmiller/work/mysql/tmpmerge

Under high load it was possible that memory mapping was started on a table
while other threads were working with the table.

I fixed the start of memory mapping so that it is done at the first table
open or when the requesting thread is using the table exclusively only.

  Rename: BitKeeper/deleted/.del-README.txt -> BitKeeper/deleted/.del-README.txt-renamed

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint

into  olga.mysql.com:/home/igor/mysql-5.1-opt

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.1-new-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.1-new-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint