2

私は、結合された配列の背後にある IPC メカニズムの実装の詳細を隠すというアイデアをいじくり回しています。目標は、サーバー側で次のようなことができるようにすることです。

# setup code here. Client provides a function name, we find
# a function to deal with the request:
my $coderef = lookup($method);
local @_;
tie @_, 'My::IPC';
@ret = &$coderef;

このMy::IPCクラスは、必要に応じてパイプ/ソケットからシリアル化されたオブジェクトを読み取ります (SHIFTまたはFETCH メソッドによってトリガーされます)。

サーバー関数の作成者に、IPC アクセス可能な関数をローカル関数を作成するのと同じ方法で作成する方法を提供したいと思います。つまり、次のようになります。

sub f1 {
    while (my $param = shift) {
        ...
    }
}

... としても ...

sub f2 {
    my ($foo, $bar, $baz, %flags) = @_;
    ...
}

f1使用可能な RAM の量よりも大きい可能性のあるデータのストリームを処理できるようにすることを目的としています。デシリアライズ後に個々のオブジェクトが RAM に収まる限り、すべて問題ありません。f2 引数リストをRAMに丸呑みできる「より単純な」関数を対象としています。

両方のシナリオをサポートするには、コンストラクターと TIEARRAY、、、およびメソッドを実装する必要があります。その部分は解決したと思います。気になるのは、値を送信できる方法が見つからないように見えることです。リスト コンテキストであっても、空の配列で使用すると返されるためです。何かのようなものSHIFTFETCHFETCHSIZEundeff1shiftundef

@params = splice @_, 0, 1;

ここでうまくいくかもしれませんが、それはユーザーにとって明らかな解決策のようには見えません。

少し変更を加えて、利用可能なデータがある限り 1 を返すようにf1実装することで、これを解決できます。FETCHSIZE

sub f3 {
    while (@_) {
        my $param = shift;
        ...
    }
}

f2ただし、最初の要素のみが割り当てられるため、これは壊れます。どうやら、FETCHSIZE正確な値を提供する必要がありますが、その正確な値を取得するには、配列全体を RAM に丸呑みする必要があります。これは、反復処理の目的を無効にします。

「ストリーミング」モデル ( f1f3) と、より単純な関数呼び出しのようなモデル ( f2) の両方を、同じ結ばれた配列の実装でサポートするエレガントな方法はありますか?

4

1 に答える 1