REPAIR TABLE导致死锁

问题表现：
以 discuz 论坛的帖子数据表(cdb_posts)为例，该表有 887106 条记录，正常情况下，在一个 P4 2.4G、1G 内存的 PC 机上执行 REPAIR TABLE 的耗时大概 95s，如下：

mysql> SHOW GLOBAL VARIABLES LIKE 'myisam_repair_threads';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| myisam_repair_threads | 1     | 
+-----------------------+-------+

mysql> REPAIR TABLE cdb_posts;
+-----------------+--------+----------+----------+
| Table           | Op     | Msg_type | Msg_text |
+-----------------+--------+----------+----------+
| Forum.cdb_posts | repair | status   | OK       | 
+-----------------+--------+----------+----------+
1 row in set (1 min 35.58 sec)

而同等硬件条件下，如果把 myisam_repair_threads 设置成 >1(例如7，设置完之后记得重启 MySQL) 的话，则会有问题，表现为 REPAIR 进程类似发生死锁的状况，一直无法完成，如下：

mysql> SHOW GLOBAL VARIABLES LIKE 'myisam_repair_threads';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| myisam_repair_threads | 2     | 
+-----------------------+-------+

mysql> REPAIR TABLE cdb_posts;

再找个终端登录 MySQL，执行 SHOW PROCESSLIST 可以看到如下情况：

mysql> SHOW PROCESSLIST;
....
|  1 | root | localhost | Forum | Query   |  1330 | Repair with 7 threads | REPAIR TABLE cdb_posts | 
....

最后，google了一下，发现也有其他人报告这个bug，详情请看：OPTIMIZE TABLE cause race condition in IO CACHE SHARE，号称是在 5.0.40 已经修复了，可是我用的版本是 5.0.45，却依然存在，谁碰到同样的情况请不吝留下言，谢谢 :)