Bug#25460 - High concurrency MyISAM access causes severe mysqld crash.

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.


storage/myisam/mi_extra.c:
  Bug#25460 - High concurrency MyISAM access causes severe mysqld crash.
  Allow to memory map while table is in use.

storage/myisam/mi_extra.c

@@ -350,11 +350,13 @@ int mi_extra(MI_INFO *info, enum ha_extra_function function, void *extra_arg)
 #ifdef HAVE_MMAP
     pthread_mutex_lock(&share->intern_lock);
     /*
-      Memory map the data file if it is not already mapped and if there
-      are no other threads using this table. intern_lock prevents other
-      threads from starting to use the table while we are mapping it.
+      Memory map the data file if it is not already mapped. It is safe
+      to memory map a file while other threads are using file I/O on it.
+      Assigning a new address to a function pointer is an atomic
+      operation. intern_lock prevents that two or more mappings are done
+      at the same time.
     */
-    if (!share->file_map && (share->tot_locks == 1))
+    if (!share->file_map)
     {
       if (mi_dynmap_file(info, share->state.state.data_file_length))
       {