10

actor_タイプのプロパティを持つクラスがあるとしますActor。私がやっていることに問題がありますか

def someMethod() = {
  actor_ ! "HELLO"
}

または、メッセージの送信は常に別のアクターから行う必要があります。例えば

def someMethod() = {
  Actor.actor { actor_ ! "HELLO" }
}
4

2 に答える 2

8

場合によります。アクター以外のコードからアクターにメッセージを送信すると、ActorProxyが自動的に作成され、ローカルスレッドに格納されます。これにより、スレッドがGCされるまでActorProxyがGCされないため、非常に小さいものの、潜在的なメモリリークが発生します。ActorProxyは基本的に、非アクタースレッドがメッセージの受信を含む多くの方法でアクターのように動作することを可能にします。

より大きな問題は、アクターライブラリがスレッドを管理する方法と同様に、スレッドが管理されている場合です。これにより、論理コンテキストを表すものが、あるスレッドにある場合と、別のスレッドにある場合があります。この良い例は、サーブレットコンテナです。論理コンテキストはサーブレットまたはセッションの場合がありますが、ActorProxyはスレッドにバインドされるため、論理コンテキスト間で共有されます。アクターがActorProxyに返信していない場合、これはそれほど大きな問題ではありませんが、返信がある場合は、(a)返信が間違ったコンテキストで受信される可能性があるため、または(b)メッセージは受信されないため、ActorProxiesのメールボックスがいっぱいになると、前述の小さなリークが大きなリークになります。

[編集]うーん...質問を読むのに問題があるようです!アクターブロックでそれを囲むと、終了時に適切にGCされる新しいアクターオブジェクトが作成されます。メッセージ送信をアクターブロックに入れるということは、メッセージ送信が、アクターを作成するスレッドではなく、別のスレッドの新しいリアクションで行われることを意味することに注意してください。

于 2009-06-30T11:23:02.320 に答える
0

私はそれをすることに問題はないと思います。それがあなたのコードで理にかなっているなら、なぜそうではありませんか?純粋なアクターモデルを見ると、すべてがアクターであり、アクターのみが相互に通信しています。このようにコードを設計できる場合は、送信できないか、送信したくない場合は、送信してもかまいません。非アクターからアクターへのメッセージ。

于 2009-06-29T22:39:31.670 に答える