<!--
   $FML: lock.sgml,v 1.4 2004/10/06 09:07:39 fukachan Exp $
-->


<chapter id="lock">
	<title>
	ロック
	</title>

<para>
プロセス間の同期化はロックを用いて行ないます。fml8 でサポートされてい
るロックメカニズムは flock(2) or lockf(2) を元にしたロック機構のみです。
</para>


<sect1 id="lock.overview">
	<title>
	ロックの概要
	</title>

<para>
ながらく giant lock でしたが、2003/03 に giant lock をなくしました。
</para>

<para>
現在では、いろいろなりソースごとに、ロックチャンネルが用意されています。
</para>

<para>
たとえば、Mail::Delivery 関連はメンバーリストにアクセスするので、いろ
いろとロックが必要です。
</para>

<para>
Mail::Delivery::SMTP の操作の際にはメンバーリストのロックが必要です。
現在は、Mail::Delivery::SMTP を呼び出す FML のクラス(実は FML::Send と 
FML::Process::Delivery の２箇所しかない)の中でロック処理をしています。
</para>

<para>
一方、Mail::Delivery::Queue は見るだけ (mailq コマンド)か、並列操作可
能なものだけなので、ロックは考えなくて良いはずです。
</para>

<para>
そして、write lock とは限らないが、一般に map を使うモジュールには
ロックが必要です。write が必要とは限りません。
たとえば
FML/Command/UserControl.pm 
や
FML/Command/Auth.pm
には write lock が必要ですが、
FML/Credential.pm
は read lock だけでよいです。
</para>

<para>
しかしながら、いまのところ reader writer lock は実装されていませんので、
リソースごとの細かいロック制御で critical region の時間を短くするよう
になっています。
</para>

</sect1>


<sect1 id="lock.todo">
	<title>
	TODO
	</title>

<para>
*_maps をよぶまえには MUTEX でロックをする。いや、やりすぎかもしれません。
</para>

<para>
メンバーリストへ IO::Adapter をかます時に、
READER WRITER LOCK がほしい。
<footnote>
<para>
READ ロックは不要か？いや、だめだろ
chaddr の途中で sleep したら敗けやから;)
</para>
</footnote>
perl thread をつかえばできるけど、
汎用的な実装はかなりむつかしいぽい;)
</para>

</sect1>


</chapter>
