2

これは PHP Zend 試験の問題です。

flock() を使用してストリームをロックすることは、どのような状況でのみ動作することが保証されていますか?

  • Linux 環境のローカル ファイルシステムで実行する場合
  • ローカルファイルシステムのストリームにアクセスするとき
  • Windows 環境で実行し、共有にアクセスする場合
  • 双方向ストリームにアクセスする場合
  • 読み取り専用ストリームにアクセスする場合
4

2 に答える 2

5

ストリームには、この一連の操作があります– write, read, close, flush(操作がない場合でも必須) およびseek, cast, stat(set_optionオプション)。ファイル ロックを要求すると、set_option操作が呼び出されます。

ここだけで、双方向または読み取り専用であることはこれとは何の関係もないことがわかります。オプションであるため、任意のラッパーを実装し、書き込みと読み取りに何らかの効果を持たせ、実装しないこともできset_optionます。同様に、no-opwrite操作を実装しても、私のset_option実装ではファイル ロックを処理できます。重要なのはストリームがサポートするものであるため、Linux 環境で実行することも重要ではありません。

（注：「Linux環境のローカルファイルシステムで実行する」が何を意味するのかわかりません。たとえば、「LinuxでAFSファイルシステムからPHPを実行する」ではなく、「Linux環境でローカルファイルシステムからPHPを実行する」ことを意味することを認めました環境」。これが「Linux 環境でローカル ファイルシステムをサポートするストリームにアクセスする」ことを意味する場合、以下に説明する手動の警告を考えると、これはおそらく正しい答えです)。

残りの質問は、STDIO ストリームに関するものです。さて、ストリームが でブロッキングをサポートしているかどうかを確認するときstream_supports_lock、PHP は実際にフロックを試行せず、set_option「このストリームはファイル ロックをサポートしているか」を問い合わせる特別な値を操作に渡します。STDIO ストリーム操作は常に応答するので、残りの 2 つの回答はすべて正しいように見えます。

ただし、set_option操作がファイルのロックをサポートしていると主張しているという事実は、それが真実であるとは言えません。実際にロックを取得しようとすると、失敗することがあります。では、いつ動作することが保証されますか? これらはほとんど何でもバックアップできるため、確かにWindows共有ではありません。「ローカルファイルシステム上」が残っています。答えは消去法で

ローカルファイルシステムのストリームにアクセスするとき

ただし、マニュアルの (確かに古い) 警告に注意してください。

flock() は、FAT やその派生物のような時代遅れのファイルシステムではサポートされていないため、この [sic] 環境では常に FALSE を返します (これは特に Windows 98 ユーザーに当てはまります)。

于 2010-06-23T00:51:47.747 に答える
1

ああ、良い質問です。

ストリームがロックをサポートしているかどうかのチェックは 5.3 で追加されたばかりですが、streamWrapper サンプル クラスにはstream_lock「常に」存在しているように見える メソッドがあります。は、ブロックできるストリームでstream_lockも機能することを示唆しています。

ソケットをフロックできるとは思わないので、答えは＃2のようです。ストリームが（ローカル）ファイルの場合、ストリームのフロックが機能することを安全に知ることができます。

(リモート ファイル (NFS、CIFS) で flock がどのように動作するかは、それらのリモート ファイルを提供するサービス次第です。たとえば、さまざまな NFS デーモンの古いバージョンの中には、flock をまったくサポートしていないものがあります。)

于 2010-06-22T23:51:13.807 に答える