マルチコアのCPUの時代になって、AppleScriptでも並列処理が行えると有利だということが分かってきた。数千ファイルの画像の破損チェックを、１本のプログラムで行うよりも……各ディレクトリに１本のスレッドで処理させたほうが何倍も速く処理できる。
そんなわけで、スレッド生成というかインスタンスの生成を、AppleScriptから実施。これは何か特別なテクノロジーを用いるのではなく、単にファイルベースでスレッドを分離（コピー）して、それぞれのランタイムアプリケーションを識別できるようにInfo.plistを書き換えるだけの話だ。
そして、スレッドを順次起動してパラメータを渡して実行……ということになる。だいたい、前に試したときにはシングルタスクのプログラムの7～8倍は高速に処理できた。
ところが、このやり方には１つの問題があった。
処理が終わったことやエラーが起こったことを、タスク側からメイン側に伝える方法がない。終了後に子タスクが自動で終了するようにしておけば、メイン側から子タスクの存在を一定間隔で調査すれば終了については検出できる。ただ、異常終了とかプロセスがストール（異常迷走）していることは検出できない。
AppleEventを送るのは……相互に送りあうとデッドロックがかかる可能性があるので、あまりよろしくない。子タスク側からメイン側のハンドラを呼んだりすると、非同期で処理できない。
子タスク側から実行結果の情報をファイルに書き出しておいてもいいが、メイン側で結果ファイルが書き出されたことを常時監視しないといけない。
……ここで妙案が思い浮かばなかったので、しばらく棚上げしておいた。
だが、唐突に答えが見つかる。サブ側で伝達事項をファイルに書き出しておいて、メイン側のアプリケーションにこの書類をオープンするイベントを送るのだ。つまり、子タスク側から結果をファイルに書き出して、メイン側のアプリにドラッグ＆ドロップしまくるようなイメージだ。
ファイルOpenイベントが発生して、openイベントハンドラが呼ばれる。パスが渡るので、その書類の内容を確認する……ということになる。ファイルオープンのイベントに関しては非同期で実行され……かつ、OS側でイベントのキューイングも自動でやってくれるはずだ。
そんなことが実際に可能というか、安定して運用できるのか確信が持てなかったので、テストプログラムを作成して実行してみた。
結果は大成功。そんなに頻繁に結果をメイン側に返すものでもないが、結果を返すだけのサブ処理プログラムを複数起動し、結果を受け取るようにしたが……とくに動作がおかしくなったり途中でイベントが抜けるようなこともなかった。
目下、Mac OS X 10.5をターゲットにしてAppleScript Studioでメイン側のプログラムを作成してテストを行ってきた。AppleScriptObjCでこれを書き換えるのも簡単なので、試してみてもよいだろう。
いろいろ応用範囲が広がっていくことだろう。