Using fantom 1.0.57 (java runtime, version: 1.6.0_24).
peterSun 27 Feb 2011
My understanding is that Actor.locals are not local to an actor, like an instance variable is. They come into existence only for an actor within a given thread. See #1158 for an earlier discussion.
The only objects I manage to store in an actor's constructor are those created and used in a GUI thread (like the example in examples/fwt/clock.fan), because that's the only thread you can be sure of.
For non-GUI objects, I use an init message to set up Actor.locals in receive, and then I am able to retrieve and use the values on sending an action message to the actor.
paulSun 27 Feb 2011
Thanks peter. But there is one more thing I'd like to ask. How one can pass InStream to an Actor?
vkuzkokovSun 27 Feb 2011
The perfect solution is to open InStream in the actor's thread (e.g. by passing File or Uri). That will guarantee that no two threads will ever read from it.
If you still feel need for passing mutable objects between actors then sys::Unsafe is the way to do it.
brianMon 28 Feb 2011
Just to recap:
what happens in your Actor's constructor is happening inside the actor/thread who is doing the constructing
only what happens inside your receive method is actually inside your actor's thread
actor locals are essentially just like Java/C# thread local with the difference that actors move around to multiple threads as their scheduled and the actor locals travel with them
In general the best design techniques are:
save state from construction to const fields in your actor (must be immutable)
pass construction state using an init message (must be immutable/serializable)
paul Sun 27 Feb 2011
Actor.locals
initialized insidemake
constructor ofActor
, but insidereceive
method they are empty.Output:
Using fantom 1.0.57 (java runtime, version: 1.6.0_24).
peter Sun 27 Feb 2011
My understanding is that
Actor.locals
are not local to an actor, like an instance variable is. They come into existence only for an actor within a given thread. See #1158 for an earlier discussion.The only objects I manage to store in an actor's constructor are those created and used in a GUI thread (like the example in examples/fwt/clock.fan), because that's the only thread you can be sure of.
For non-GUI objects, I use an
init
message to set up Actor.locals inreceive
, and then I am able to retrieve and use the values on sending anaction
message to the actor.paul Sun 27 Feb 2011
Thanks peter. But there is one more thing I'd like to ask. How one can pass
InStream
to anActor
?vkuzkokov Sun 27 Feb 2011
The perfect solution is to open
InStream
in the actor's thread (e.g. by passingFile
orUri
). That will guarantee that no two threads will ever read from it.If you still feel need for passing mutable objects between actors then
sys::Unsafe
is the way to do it.brian Mon 28 Feb 2011
Just to recap:
In general the best design techniques are: