T
Tony Arcieri
[Note: parts of this message were removed to make it a legal post.]
After talking with MenTaLguY about this he convinced me subclassing Actor
from Fiber was dumb, particularly in regard to thread safety. In the trunk
I'm working on a version where Actors are independent from their underlying
fibers. Among other things this means that an Actors can be used anywhere
in your program, and will be lazily created if one doesn't currently exist.
And, as you mentioned, it will also be possible to cleanly create subclasses
of Actor which don't use a fiber underneath (e.g. a distributed Actor
protocol built on top of DRb)
Not as yet, no
It's interestnig that you chose the make Actor inherit from Fiber. I'm
not sure but I think one side-effect of this is that it makes it
impossible to run an actor in another process transparently (which, if
you're using a fully functional programming style, it should be possible
to do).
After talking with MenTaLguY about this he convinced me subclassing Actor
from Fiber was dumb, particularly in regard to thread safety. In the trunk
I'm working on a version where Actors are independent from their underlying
fibers. Among other things this means that an Actors can be used anywhere
in your program, and will be lazily created if one doesn't currently exist.
And, as you mentioned, it will also be possible to cleanly create subclasses
of Actor which don't use a fiber underneath (e.g. a distributed Actor
protocol built on top of DRb)
Have you done any performance measurements to compare against a threaded
model?
Not as yet, no