Perlの組み込み関数 flock の翻訳

perl-5.40.0

flock FILEHANDLE,OPERATION

Calls flock(2), or an emulation of it, on FILEHANDLE. Returns true for success, false on failure. Produces a fatal error if used on a machine that doesn't implement flock(2), fcntl(2) locking, or lockf(3). flock is Perl's portable file-locking interface, although it locks entire files only, not records.

FILEHANDLE に対して flock(2)、またはそのエミュレーションを呼び出します。成功時には真を、失敗時には偽を返します。 flock(2), fcntl(2) ロック, lockf(3) のいずれかを実装していないマシンで使うと、致命的エラーが発生します。 flock は Perl の移植性のあるファイルロックインターフェースです; しかしレコードではなく、ファイル全体のみをロックします。

Two potentially non-obvious but traditional flock semantics are that it waits indefinitely until the lock is granted, and that its locks are merely advisory. Such discretionary locks are more flexible, but offer fewer guarantees. This means that programs that do not also use flock may modify files locked with flock. See perlport, your port's specific documentation, and your system-specific local manpages for details. It's best to assume traditional behavior if you're writing portable programs. (But if you're not, you should as always feel perfectly free to write for your own system's idiosyncrasies (sometimes called "features"). Slavish adherence to portability concerns shouldn't get in the way of your getting your job done.)

明白ではないものの、伝統的な flock の動作としては、ロックが得られるまで無限に待ち続けるものと、単に勧告的に ロックするものの二つがあります。このような自由裁量のロックはより柔軟ですが、保障されるものはより少ないです。これは、flock を使わないプログラムが flock でロックされたファイルを書き換えるかもしれないことを意味します。詳細については、perlport、システム固有のドキュメント、システム固有のローカルの man ページを参照してください。移植性のあるプログラムを書く場合は、伝統的な振る舞いを仮定するのがベストです。 (しかし移植性のないプログラムを書く場合は、自身のシステムの性癖(しばしば「仕様」と呼ばれます)に合わせて書くことも完全に自由です。盲目的に移植性に固執することで、あなたの作業を仕上げるのを邪魔するべきではありません。)

OPERATION is one of LOCK_SH, LOCK_EX, or LOCK_UN, possibly combined with LOCK_NB. These constants are traditionally valued 1, 2, 8 and 4, but you can use the symbolic names if you import them from the Fcntl module, either individually, or as a group using the :flock tag. LOCK_SH requests a shared lock, LOCK_EX requests an exclusive lock, and LOCK_UN releases a previously requested lock. If LOCK_NB is bitwise-or'ed with LOCK_SH or LOCK_EX, then flock returns immediately rather than blocking waiting for the lock; check the return status to see if you got it.

OPERATION は LOCK_SH, LOCK_EX, LOCK_UN のいずれかで、LOCK_NB と組み合わされることもあります。これらの定数は伝統的には 1, 2, 8, 4 の値を持ちますが、Fcntl モジュールからシンボル名を独立してインポートするか、:flock タグを使うグループとして、シンボル名をを使うことができます。 LOCK_SH は共有ロックを要求し、LOCK_EX は排他ロックを要求し、LOCK_UN は前回要求したロックを開放します。 LOCK_NB と LOCK_SH か LOCK_EX がビット単位の論理和されると、 flock はロックを取得するまで待つのではなく、すぐに返ります; ロックが取得できたかどうかは返り値を調べます。

To avoid the possibility of miscoordination, Perl now flushes FILEHANDLE before locking or unlocking it.

不一致の可能性を避けるために、Perl はファイルをロック、アンロックする前に FILEHANDLE をフラッシュします。

Note that the emulation built with lockf(3) doesn't provide shared locks, and it requires that FILEHANDLE be open with write intent. These are the semantics that lockf(3) implements. Most if not all systems implement lockf(3) in terms of fcntl(2) locking, though, so the differing semantics shouldn't bite too many people.

lockf(3) で作成されたエミュレーションは共有ロックを提供せず、 FILEHANDLE が書き込みモードで開いていることを必要とすることに注意してください。これは lockf(3) が実装している動作です。しかし、全てではないにしてもほとんどのシステムでは fcntl(2) を使って lockf(3) を実装しているので、異なった動作で多くの人々を混乱させることはないはずです。

Note that the fcntl(2) emulation of flock(3) requires that FILEHANDLE be open with read intent to use LOCK_SH and requires that it be open with write intent to use LOCK_EX.

flock(3) の fcntl(2) エミュレーションは、 LOCK_SH を使うためには FILEHANDLE を読み込みで開いている必要があり、LOCK_EX を使うためには書き込みで開いている必要があることに注意してください。

Note also that some versions of flock cannot lock things over the network; you would need to use the more system-specific fcntl for that. If you like you can force Perl to ignore your system's flock(2) function, and so provide its own fcntl(2)-based emulation, by passing the switch -Ud_flock to the Configure program when you configure and build a new Perl.

ネットワーク越しにはロックできない flock もあることに注意してください; このためには、よりシステム依存な fcntl を使う必要があります。 Perl にシステムの flock(2) 関数を無視させ、自身の fcntl(2) ベースのエミュレーションを使う場合は、新しい Perl を設定およびビルドするときに Configure プログラムに -Ud_flock オプションを渡してください。

Here's a mailbox appender for BSD systems.

BSD システムでのメールボックスへの追加処理の例を示します。

    # import LOCK_* and SEEK_END constants
    use Fcntl qw(:flock SEEK_END);

    sub lock {
        my ($fh) = @_;
        flock($fh, LOCK_EX) or die "Cannot lock mailbox - $!\n";
        # and, in case we're running on a very old UNIX
        # variant without the modern O_APPEND semantics...
        seek($fh, 0, SEEK_END) or die "Cannot seek - $!\n";
    }

    sub unlock {
        my ($fh) = @_;
        flock($fh, LOCK_UN) or die "Cannot unlock mailbox - $!\n";
    }

    open(my $mbox, ">>", "/usr/spool/mail/$ENV{'USER'}")
        or die "Can't open mailbox: $!";

    lock($mbox);
    print $mbox $msg,"\n\n";
    unlock($mbox);

On systems that support a real flock(2), locks are inherited across fork calls, whereas those that must resort to the more capricious fcntl(2) function lose their locks, making it seriously harder to write servers.

真の flock(2) に対応しているシステムではロックは fork を通して継承されるのに対して、より不安定な fcntl(2) に頼らなければならない場合、サーバを書くのは本当により難しくなります。

See also DB_File for other flock examples.

その他の flock の例としては DB_File も参照してください。

Portability issues: "flock" in perlport.

移植性の問題: "flock" in perlport。