POPFile::Mutex を flock() を使わない方法に書き換える

やはり flock() は Windows 98 などでは使用できないようなので、他の方法を考える。
Perl で排他制御をする場合、flock() が使えない環境では mkdir() でディレクトリを作成する（ディレクトリが存在する間はロック中）という方法があるらしい。この方法を使った場合、ディレクトリが存在している間（ロックしている間）にプロセスが異常終了してしまうとディレクトリが消えずに残ってしまうという問題があり、作られてからある程度時間のたったディレクトリは自動的に削除するといった処理が必要になるようだけど、幸い、今回はプロセス間の排他制御ではなく、同一プロセスのスレッド間の排他制御なので、初めてロックをかける前にディレクトリを削除すれば問題なさそうだ。
ということで、早速書き換え。できるだけ元のコードを変更しないように気をつけながら修正していく。また、他のファイル（Classifier/MailParse.pm とか）を修正しなくてもそのままで動くように配慮する。
何度か試行錯誤して、一応動くものができた。もとのファイルと入れ替えて動かしてみても問題ない（いや、実は、RC2 を使用して Mutex 用のファイルが残っている場合はまったく動かない。これは、ファイルと同じ名前のディレクトリを作成することができないのと、ディレクトリを削除する rmdir() ではファイルは削除できないため。この場合、POPFile フォルダにある popfile_mutex_mailparse_kakasi.mtx を削除しておけばちゃんと動くようになる）。テスト用に作成したプログラムを走らせても問題ない。POPFile のテスト・スイートもパスした。
ディレクトリを作成、削除しているだけなので、環境に依存せず動くはず。Windows 98 でも問題なく動いた（テストもパス）。Mac OS X 10.3.6 でもちゃんと動いた。パフォーマンスのことを考えれば、flock() が使える環境であれば flock() を、使えない環境であれば mkdir() を使うというようにすべきなのだろうけど、flock() が使えるのかどうかを調べる方法がわからないので（eval で flock() を実行したときにエラーが起こるかどうかを調べるという手があるようだけど、エラーは起こらないけれどロックとして役に立たないというケースもあるような気がする）現在の実装では mkdir() のみを使用するようした。
作成したコードと 0.22.2RC2 からのパッチは、本家パッチセクションに登録した。これで問題が解決するといいのだけど。