Actors in 2.8

It is protected, inherited from Reactor, now.     On Thu, Aug 20, 2009 at 12:51 PM, Paul J. LaCrosse <pjlacrosse@yahoo.com> wrote:

It seems that the .mailboxSize method is no longer available for Actor
instances in 2.8 (at least using yesterday's nightly Eclipse plugin).

Has it been permanently removed such that an actor may not be queried "from
the outside" of its pending message count?
--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25064760.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

Why the change. I see that it is protected to the scala.actors package.

Users create actors by extending Actor, and wouldn't put our code into the
scala.actors package. So now, this method, from within one of my actors to
query the pending message count from an array of sub-actors, can no longer
work:

val actors: Array[Actor] = new Array[Actor(maxWorkers)
.
.
.
.

def workerMailboxSizes: List[Int] = (actors map (_.mailboxSize)).toList

This ability is very useful for load-balancing work by looking for actors
with "less-full" mailboxes.

Daniel Sobral wrote:
>
> It is protected, inherited from Reactor, now.
>

I don't know, but as a general API do Actors it's not very good, because it implies a certain structure that may not exist with different Actor implementations.   It should be pretty easy to fix, by extending Actor and adding a public method back to it. Though simple, I can see that it might require extensive changes.   At any rate, go look who made the change, and ask him directly.

On Thu, Aug 20, 2009 at 1:58 PM, Paul LaCrosse <pjlacrosse@yahoo.com> wrote:

Why the change.  I see that it is protected to the scala.actors package.

Users create actors by extending Actor, and wouldn't put our code into the
scala.actors package.  So now, this method, from within one of my actors to
query the pending message count from an array of sub-actors, can no longer
work:

val actors: Array[Actor] = new Array[Actor(maxWorkers)
.
.
.
.

def workerMailboxSizes: List[Int] = (actors map (_.mailboxSize)).toList

This ability is very useful for load-balancing work by looking for actors
with "less-full" mailboxes.


Daniel Sobral wrote:
>
> It is protected, inherited from Reactor, now.
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic
> reviews:
> review by name, review by reference and review by value.
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25065962.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

We had a discussion about this at the Scala Lift Off.  Philipp has asked me to review the API based on our suggestion, but I haven't had the time.

Basically, my recommendation was to split the interfaces between the external facing APIs and implementation details.  These would be consumed at the application level.  Basically, the methods used to communicate with the Actor (!, !!, !?).  The implementation details would be a separate trait that would not expose any methods.  The implementation details may include mailbox access (or size), failure management (e.g., linking, exception handler, etc.), and other stuff.

That way, anything with the external Actor interface could be interacted with by API consumers.  The implementation choice could be chosen at development (or even run) time.

On Thu, Aug 20, 2009 at 10:27 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

I don't know, but as a general API do Actors it's not very good, because it implies a certain structure that may not exist with different Actor implementations.   It should be pretty easy to fix, by extending Actor and adding a public method back to it. Though simple, I can see that it might require extensive changes.   At any rate, go look who made the change, and ask him directly.

On Thu, Aug 20, 2009 at 1:58 PM, Paul LaCrosse <pjlacrosse@yahoo.com> wrote:

Why the change.  I see that it is protected to the scala.actors package.

Users create actors by extending Actor, and wouldn't put our code into the
scala.actors package.  So now, this method, from within one of my actors to
query the pending message count from an array of sub-actors, can no longer
work:

val actors: Array[Actor] = new Array[Actor(maxWorkers)
.
.
.
.

def workerMailboxSizes: List[Int] = (actors map (_.mailboxSize)).toList

This ability is very useful for load-balancing work by looking for actors
with "less-full" mailboxes.


Daniel Sobral wrote:
>
> It is protected, inherited from Reactor, now.
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic
> reviews:
> review by name, review by reference and review by value.
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25065962.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Well, I'd like to suggest then that mailboxSize (or something similar that
shows the pending message count) be part of the public API for Actors.

I use it, to great effect, for load-balancing the submission of tasks to
arrays of actors.

bearfeeder wrote:
>
> We had a discussion about this at the Scala Lift Off. Philipp has asked
> me
> to review the API based on our suggestion, but I haven't had the time.
>
> Basically, my recommendation was to split the interfaces between the
> external facing APIs and implementation details. These would be consumed
> at
> the application level. Basically, the methods used to communicate with
> the
> Actor (!, !!, !?). The implementation details would be a separate trait
> that would not expose any methods. The implementation details may include
> mailbox access (or size), failure management (e.g., linking, exception
> handler, etc.), and other stuff.
>
> That way, anything with the external Actor interface could be interacted
> with by API consumers. The implementation choice could be chosen at
> development (or even run) time.
>
>

On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse <paul.lacrosse@gmail.com> wrote:

Well, I'd like to suggest then that mailboxSize (or something similar that
shows the pending message count) be part of the public API for Actors.

That would be a terrible idea in my opinion.  The Mailbox size has nothing to do with sending a message.  It's all about the implementation.  For remote Actors, having a mailbox size would radically increase the complexity of the implementation.  For Lift Actors, the materialization of the mailbox is done at message processing time to minimize the time in monitor.  Having a mailbox count method publicly exposed would make that logic a ton more difficult.  If your mailbox is an AMQP server someplace, there may or may not be a way of getting the mailbox size.
 

I use it, to great effect, for load-balancing the submission of tasks to
arrays of actors.

Then you can create:

Actor with MyManagementStuff

The MyManagementStuff would expose whatever management stuff you needed, but it would be tied to the Actor implementation you've chosen and not forced on every Actor implementor.
 

bearfeeder wrote:
>
> We had a discussion about this at the Scala Lift Off.  Philipp has asked
> me
> to review the API based on our suggestion, but I haven't had the time.
>
> Basically, my recommendation was to split the interfaces between the
> external facing APIs and implementation details.  These would be consumed
> at
> the application level.  Basically, the methods used to communicate with
> the
> Actor (!, !!, !?).  The implementation details would be a separate trait
> that would not expose any methods.  The implementation details may include
> mailbox access (or size), failure management (e.g., linking, exception
> handler, etc.), and other stuff.
>
> That way, anything with the external Actor interface could be interacted
> with by API consumers.  The implementation choice could be chosen at
> development (or even run) time.
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25066710.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Hmmmm.... perhaps I can see your logic.

On the other hand, implementations that are unable to determine the count
could easily return -1, or null, or None.

Since all of the actor projects I've written use load-balancing on arrays of
actors, which determine that the next message goes to the actor that
currently has the fewest messages in their box, I'm biased towards believing
that this ability is absolutely critical for high-performance actor
applications.

;-)

bearfeeder wrote:
>
> On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse
> wrote:
>
>>
>> Well, I'd like to suggest then that mailboxSize (or something similar
>> that
>> shows the pending message count) be part of the public API for Actors.
>
>
> That would be a terrible idea in my opinion. The Mailbox size has nothing
> to do with sending a message. It's all about the implementation. For
> remote Actors, having a mailbox size would radically increase the
> complexity
> of the implementation. For Lift Actors, the materialization of the
> mailbox
> is done at message processing time to minimize the time in monitor.
> Having
> a mailbox count method publicly exposed would make that logic a ton more
> difficult. If your mailbox is an AMQP server someplace, there may or may
> not be a way of getting the mailbox size.
>
>
>>
>>
>> I use it, to great effect, for load-balancing the submission of tasks to
>> arrays of actors.
>
>
> Then you can create:
>
> Actor with MyManagementStuff
>
> The MyManagementStuff would expose whatever management stuff you needed,
> but
> it would be tied to the Actor implementation you've chosen and not forced
> on
> every Actor implementor.
>
>
>

... continuing with this thought, implementations that are unable to tell how
many messages are in their queue/box could just send 0 (zero) back when
their box is empty (ie: they are not busy), and -1 (or integer maximum
value, perhaps) if they are busy. At least the balancing algorithm would
still have a chance of working somewhat by giving empty mailboxes messages
first.

Besides, this method (mailboxSize) has been available for a while, and
should at least have a deprecation period before dropping it completely, if
that turns out to be the direction, in spite of my contrary exhortations.

Paul LaCrosse wrote:
>
> Hmmmm.... perhaps I can see your logic.
>
> On the other hand, implementations that are unable to determine the count
> could easily return -1, or null, or None.
>
> Since all of the actor projects I've written use load-balancing on arrays
> of actors, which determine that the next message goes to the actor that
> currently has the fewest messages in their box, I'm biased towards
> believing that this ability is absolutely critical for high-performance
> actor applications.
>
> ;-)
>
>
>
> bearfeeder wrote:
>>
>> On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse
>> wrote:
>>
>>>
>>> Well, I'd like to suggest then that mailboxSize (or something similar
>>> that
>>> shows the pending message count) be part of the public API for Actors.
>>
>>
>> That would be a terrible idea in my opinion. The Mailbox size has
>> nothing
>> to do with sending a message. It's all about the implementation. For
>> remote Actors, having a mailbox size would radically increase the
>> complexity
>> of the implementation. For Lift Actors, the materialization of the
>> mailbox
>> is done at message processing time to minimize the time in monitor.
>> Having
>> a mailbox count method publicly exposed would make that logic a ton more
>> difficult. If your mailbox is an AMQP server someplace, there may or may
>> not be a way of getting the mailbox size.
>>
>>
>>>
>>>
>>> I use it, to great effect, for load-balancing the submission of tasks to
>>> arrays of actors.
>>
>>
>> Then you can create:
>>
>> Actor with MyManagementStuff
>>
>> The MyManagementStuff would expose whatever management stuff you needed,
>> but
>> it would be tied to the Actor implementation you've chosen and not forced
>> on
>> every Actor implementor.
>>
>>
>>
>
>

In a sense, Scala Actors are sort of sweet spotted for Concurrency and rather less so for Parallelism.  Witness the discussed pattern of Array[Actor] load balanced by inspecting the internal msg queue. 

Ray

On Thu, Aug 20, 2009 at 2:26 PM, Paul LaCrosse <paul.lacrosse@gmail.com> wrote:

Hmmmm.... perhaps I can see your logic.

On the other hand, implementations that are unable to determine the count
could easily return -1, or null, or None.

Since all of the actor projects I've written use load-balancing on arrays of
actors, which determine that the next message goes to the actor that
currently has the fewest messages in their box, I'm biased towards believing
that this ability is absolutely critical for high-performance actor
applications.

;-)



bearfeeder wrote:
>
> On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse
> <paul.lacrosse@gmail.com>wrote:
>
>>
>> Well, I'd like to suggest then that mailboxSize (or something similar
>> that
>> shows the pending message count) be part of the public API for Actors.
>
>
> That would be a terrible idea in my opinion.  The Mailbox size has nothing
> to do with sending a message.  It's all about the implementation.  For
> remote Actors, having a mailbox size would radically increase the
> complexity
> of the implementation.  For Lift Actors, the materialization of the
> mailbox
> is done at message processing time to minimize the time in monitor.
> Having
> a mailbox count method publicly exposed would make that logic a ton more
> difficult.  If your mailbox is an AMQP server someplace, there may or may
> not be a way of getting the mailbox size.
>
>
>>
>>
>> I use it, to great effect, for load-balancing the submission of tasks to
>> arrays of actors.
>
>
> Then you can create:
>
> Actor with MyManagementStuff
>
> The MyManagementStuff would expose whatever management stuff you needed,
> but
> it would be tied to the Actor implementation you've chosen and not forced
> on
> every Actor implementor.
>
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25067333.html
Sent from the Scala - User mailing list archive at Nabble.com.

In the Akka project I've separated the Actor impl from the actual dispatcher.
This makes the message delivery, thread pools, thread semantics,
message queue impl etc highly configurable.
The lack of this in the Scala Actors was one of the main reason for me
to impl my own actors (other reasons were scalable remote actors,
optional statistics, monitoring and management etc.).
See: http://wiki.github.com/jboner/akka/reference-dispatcher-seda-configuration

/Jonas

2009/8/20 Paul LaCrosse :
>
> Hmmmm.... perhaps I can see your logic.
>
> On the other hand, implementations that are unable to determine the count
> could easily return -1, or null, or None.
>
> Since all of the actor projects I've written use load-balancing on arrays of
> actors, which determine that the next message goes to the actor that
> currently has the fewest messages in their box, I'm biased towards believing
> that this ability is absolutely critical for high-performance actor
> applications.
>
> ;-)
>
>
>
> bearfeeder wrote:
>>
>> On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse
>> wrote:
>>
>>>
>>> Well, I'd like to suggest then that mailboxSize (or something similar
>>> that
>>> shows the pending message count) be part of the public API for Actors.
>>
>>
>> That would be a terrible idea in my opinion.  The Mailbox size has nothing
>> to do with sending a message.  It's all about the implementation.  For
>> remote Actors, having a mailbox size would radically increase the
>> complexity
>> of the implementation.  For Lift Actors, the materialization of the
>> mailbox
>> is done at message processing time to minimize the time in monitor.
>> Having
>> a mailbox count method publicly exposed would make that logic a ton more
>> difficult.  If your mailbox is an AMQP server someplace, there may or may
>> not be a way of getting the mailbox size.
>>
>>
>>>
>>>
>>> I use it, to great effect, for load-balancing the submission of tasks to
>>> arrays of actors.
>>
>>
>> Then you can create:
>>
>> Actor with MyManagementStuff
>>
>> The MyManagementStuff would expose whatever management stuff you needed,
>> but
>> it would be tied to the Actor implementation you've chosen and not forced
>> on
>> every Actor implementor.
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25067333.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

Changing the package of my BalanceActor to scala.actors gets rid of the
compile-error and allows access to the mailboxSize method, but do we really
want user code using the scala.actors package???

I think that the def mailboxSize method does indeed have something to do
with sending a message, in that I can check the backlog of messages already
waiting on that actor before deciding if I want to transmit any additional
messages to it at the current time.

To those in charge of the Scala Actors, please consider reversing this new
protected package[actors] on the mailboxSize def, as it was public, is
useful, is in production use, and I expect it to be of continuing utility to
myself and others.

Paul LaCrosse wrote:
>
> ... continuing with this thought, implementations that are unable to tell
> how many messages are in their queue/box could just send 0 (zero) back
> when their box is empty (ie: they are not busy), and -1 (or integer
> maximum value, perhaps) if they are busy. At least the balancing
> algorithm would still have a chance of working somewhat by giving empty
> mailboxes messages first.
>
> Besides, this method (mailboxSize) has been available for a while, and
> should at least have a deprecation period before dropping it completely,
> if that turns out to be the direction, in spite of my contrary
> exhortations.
>

Paul LaCrosse wrote:
> Changing the package of my BalanceActor to scala.actors gets rid of the
> compile-error and allows access to the mailboxSize method, but do we really
> want user code using the scala.actors package???

Note that an `Actor` subclass does not have to be in the `scala.actors`
package to be able to access its own `mailboxSize` (the qualifier in
`protected` widens its visibility). It could provide its own public
method forwarding to it:

trait MyActor extends Actor {
def mboxSize = mailboxSize
}

Cheers,
Philipp

> I think that the def mailboxSize method does indeed have something to do
> with sending a message, in that I can check the backlog of messages already
> waiting on that actor before deciding if I want to transmit any additional
> messages to it at the current time.
>
> To those in charge of the Scala Actors, please consider reversing this new
> protected package[actors] on the mailboxSize def, as it was public, is
> useful, is in production use, and I expect it to be of continuing utility to
> myself and others.
>
>
>
> Paul LaCrosse wrote:
>> ... continuing with this thought, implementations that are unable to tell
>> how many messages are in their queue/box could just send 0 (zero) back
>> when their box is empty (ie: they are not busy), and -1 (or integer
>> maximum value, perhaps) if they are busy. At least the balancing
>> algorithm would still have a chance of working somewhat by giving empty
>> mailboxes messages first.
>>
>> Besides, this method (mailboxSize) has been available for a while, and
>> should at least have a deprecation period before dropping it completely,
>> if that turns out to be the direction, in spite of my contrary
>> exhortations.
>>
>

Yes, but I was trying to avoid the breakage of existing production code, and
complicating something so simple with an extra abstract/base class or trait,
all for a method that was already a part of the public API for some time
now.

Since actors that lack the ability to determine the size could just as
easily use 0 and max int to indicated empty and full, I hoped this useful
method would remain available as part of the Actor base public API. In
other words, I think what is lost exceeds what may have been gained by this
change. As always, I'm certain others may have a different perspective on
it.

C'est la vie....

Philipp Haller-2 wrote:
>
> Note that an `Actor` subclass does not have to be in the `scala.actors`
> package to be able to access its own `mailboxSize` (the qualifier in
> `protected` widens its visibility). It could provide its own public
> method forwarding to it:
>
> trait MyActor extends Actor {
> def mboxSize = mailboxSize
> }
>
> Cheers,
> Philipp
>

On Fri, Aug 21, 2009 at 9:51 AM, Paul LaCrosse <paul.lacrosse@gmail.com> wrote:

Yes, but I was trying to avoid the breakage of existing production code, and
complicating something so simple with an extra abstract/base class or trait,
all for a method that was already a part of the public API for some time
now.

Since actors that lack the ability to determine the size could just as
easily use 0 and max int to indicated empty and full, I hoped this useful
method would remain available as part of the Actor base public API.  In
other words, I think what is lost exceeds what may have been gained by this
change.  As always, I'm certain others may have a different perspective on
it.

I strongly disagree with adding methods when they are special purpose.  In this case, it's perfectly validto create an Actor subclass as Philipp suggested or to compose a class as I suggested.  Forcing some "it works sometimes and doesn't work other times" method onto a core class strikes me as a very bad path.
 

C'est la vie....


Philipp Haller-2 wrote:
>
> Note that an `Actor` subclass does not have to be in the `scala.actors`
> package to be able to access its own `mailboxSize` (the qualifier in
> `protected` widens its visibility). It could provide its own public
> method forwarding to it:
>
>    trait MyActor extends Actor {
>      def mboxSize = mailboxSize
>    }
>
> Cheers,
> Philipp
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25083487.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

I respect your opinion, David, and agree wholeheartedly with you that adding
special purpose methods are a bad idea.

The problem is, in this case, the debate is not about *adding* anything, it
is about *taking away* something that was already there, for a reason that
is not *absolutely necessary* for the platform to progress.

The fact that several relatively simple workarounds are available doesn't
make up for the fact that previously good code will no longer compile, and a
new class/trait/method will need to be created by the developer to make up
for this feature being taken away from them, with no deprecation period or
warning.

IMHO, that is not the way to treat users of an up-and-coming platform.

Thank you to all who took the time to participate in this discussion.

bearfeeder wrote:
>
>
> I strongly disagree with adding methods when they are special purpose. In
> this case, it's perfectly validto create an Actor subclass as Philipp
> suggested or to compose a class as I suggested. Forcing some "it works
> sometimes and doesn't work other times" method onto a core class strikes
> me
> as a very bad path.
>
>

.... and besides, the new Programming Scala book due out September 25
(according to Amazon), mentions the feature as well. ;-)

http://programming-scala.labs.oreilly.com/ch09.html#_the_mailbox

Paul LaCrosse wrote:
>
> I respect your opinion, David, and agree wholeheartedly with you that
> adding special purpose methods are a bad idea.
>
> The problem is, in this case, the debate is not about *adding* anything,
> it is about *taking away* something that was already there, for a reason
> that is not *absolutely necessary* for the platform to progress.
>
> The fact that several relatively simple workarounds are available doesn't
> make up for the fact that previously good code will no longer compile, and
> a new class/trait/method will need to be created by the developer to make
> up for this feature being taken away from them, with no deprecation period
> or warning.
>
> IMHO, that is not the way to treat users of an up-and-coming platform.
>
> Thank you to all who took the time to participate in this discussion.
>
>

Paul, I think having mailboxSize publicly accessible is a very, very bad idea. If you were using it and suddenly discovered it doesn't return anything useful -- as you suggested in response to examples of where it's not viable to implement it -- I bet you'd complain bitterly.   An Actor, as a general implementation, shouldn't have it. Actual implementations of Actor may, and I think the problem here is that Actor is not being used as generic trait over which actual implementations are defined, so you don't have an T <: Actor which does have mailboxSize.   But, at any rate, YOU ARE ABSOLUTELY CORRECT that this method should have been deprecated first. It was public, after all.

On Fri, Aug 21, 2009 at 5:17 PM, Paul LaCrosse <paul.lacrosse@gmail.com> wrote:

I respect your opinion, David, and agree wholeheartedly with you that adding
special purpose methods are a bad idea.

The problem is, in this case, the debate is not about *adding* anything, it
is about *taking away* something that was already there, for a reason that
is not *absolutely necessary* for the platform to progress.

The fact that several relatively simple workarounds are available doesn't
make up for the fact that previously good code will no longer compile, and a
new class/trait/method will need to be created by the developer to make up
for this feature being taken away from them, with no deprecation period or
warning.

IMHO, that is not the way to treat users of an up-and-coming platform.

Thank you to all who took the time to participate in this discussion.


bearfeeder wrote:
>
>
> I strongly disagree with adding methods when they are special purpose.  In
> this case, it's perfectly validto create an Actor subclass as Philipp
> suggested or to compose a class as I suggested.  Forcing some "it works
> sometimes and doesn't work other times" method onto a core class strikes
> me
> as a very bad path.
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25086673.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

Ah, yes, but it is human nature to complain much more bitterly about
something one once had, but is lost, than something that one hopes to have,
but never actually received...

;-)

Besides, I think at a minimum an indication of mailbox "empty" or
"non-empty" (ie: actor has work to do or it does not) should be easily
achievable from (most) any implementation.

Daniel Sobral wrote:
>
> Paul, I think having mailboxSize publicly accessible is a very, very bad
> idea. If you were using it and suddenly discovered it doesn't return
> anything useful -- as you suggested in response to examples of where it's
> not viable to implement it -- I bet you'd complain bitterly.
>
> An Actor, as a general implementation, shouldn't have it. Actual
> implementations of Actor may, and I think the problem here is that Actor
> is
> not being used as generic trait over which actual implementations are
> defined, so you don't have an T <: Actor which does have mailboxSize.
>
> But, at any rate, YOU ARE ABSOLUTELY CORRECT that this method should have
> been deprecated first. It *was* public, after all.
>

Not really. I can easily think of Actors based on continuations where the mailbox is implicit in the call stack, and invisible to the program.

On Fri, Aug 21, 2009 at 6:28 PM, Paul LaCrosse <paul.lacrosse@gmail.com> wrote:

Ah, yes, but it is human nature to complain much more bitterly about
something one once had, but is lost, than something that one hopes to have,
but never actually received...

;-)

Besides, I think at a minimum an indication of mailbox "empty" or
"non-empty" (ie: actor has work to do or it does not) should be easily
achievable from (most) any implementation.



Daniel Sobral wrote:
>
> Paul, I think having mailboxSize publicly accessible is a very, very bad
> idea. If you were using it and suddenly discovered it doesn't return
> anything useful -- as you suggested in response to examples of where it's
> not viable to implement it -- I bet you'd complain bitterly.
>
> An Actor, as a general implementation, shouldn't have it. Actual
> implementations of Actor may, and I think the problem here is that Actor
> is
> not being used as generic trait over which actual implementations are
> defined, so you don't have an T <: Actor which does have mailboxSize.
>
> But, at any rate, YOU ARE ABSOLUTELY CORRECT that this method should have
> been deprecated first. It *was* public, after all.
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic
> reviews:
> review by name, review by reference and review by value.
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25087561.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

I can also imagine data structures for the mailbox where at any given moment trying to calculate the size would at best lead to icky lock contention and at worst be entirely meaningless.

On Fri, Aug 21, 2009 at 5:54 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Not really. I can easily think of Actors based on continuations where the mailbox is implicit in the call stack, and invisible to the program.

On Fri, Aug 21, 2009 at 6:28 PM, Paul LaCrosse <paul.lacrosse@gmail.com> wrote:

Ah, yes, but it is human nature to complain much more bitterly about
something one once had, but is lost, than something that one hopes to have,
but never actually received...

;-)

Besides, I think at a minimum an indication of mailbox "empty" or
"non-empty" (ie: actor has work to do or it does not) should be easily
achievable from (most) any implementation.



Daniel Sobral wrote:
>
> Paul, I think having mailboxSize publicly accessible is a very, very bad
> idea. If you were using it and suddenly discovered it doesn't return
> anything useful -- as you suggested in response to examples of where it's
> not viable to implement it -- I bet you'd complain bitterly.
>
> An Actor, as a general implementation, shouldn't have it. Actual
> implementations of Actor may, and I think the problem here is that Actor
> is
> not being used as generic trait over which actual implementations are
> defined, so you don't have an T <: Actor which does have mailboxSize.
>
> But, at any rate, YOU ARE ABSOLUTELY CORRECT that this method should have
> been deprecated first. It *was* public, after all.
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic
> reviews:
> review by name, review by reference and review by value.
>
>

--
View this message in context: http://www.nabble.com/Actors-in-2.8-tp25064760p25087561.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

--
http://erikengbrecht.blogspot.com/

Paul LaCrosse wrote:
> .... and besides, the new Programming Scala book due out September 25
> (according to Amazon), mentions the feature as well. ;-)
>
> http://programming-scala.labs.oreilly.com/ch09.html#_the_mailbox

Thanks for the pointer.

I looked at the code, and it turns out that it still works with trunk,
because they only use the `mailboxSize` method of the `Actor` _object_,
which is still there. This method is much less problematic, because it
can only be used to retrieve the mailbox size of the currently running
actor--you cannot use it to query an arbitrary actor.

Like most other methods in the Actor object, it's purpose is to provide
functionality to actors that are created "inline", i.e., without
sub-classing `Actor` (or `Reactor`):

import scala.actors.Actor._
actor {
println("I've got "+mailboxSize+" messages")
}

Cheers,
Philipp

> Paul LaCrosse wrote:
>> I respect your opinion, David, and agree wholeheartedly with you that
>> adding special purpose methods are a bad idea.
>>
>> The problem is, in this case, the debate is not about *adding* anything,
>> it is about *taking away* something that was already there, for a reason
>> that is not *absolutely necessary* for the platform to progress.
>>
>> The fact that several relatively simple workarounds are available doesn't
>> make up for the fact that previously good code will no longer compile, and
>> a new class/trait/method will need to be created by the developer to make
>> up for this feature being taken away from them, with no deprecation period
>> or warning.
>>
>> IMHO, that is not the way to treat users of an up-and-coming platform.
>>
>> Thank you to all who took the time to participate in this discussion.
>>
>>
>

Daniel Sobral wrote:
> But, at any rate, YOU ARE ABSOLUTELY CORRECT that this method should
> have been deprecated first. It /was/ public, after all.

I agree that it should be deprecated. Also, note that there hasn't been
any release of 2.8, yet (not even a preview), so don't take the current
state of trunk as final. :-)

Philipp

> On Fri, Aug 21, 2009 at 5:17 PM, Paul LaCrosse > wrote:
>
>
> I respect your opinion, David, and agree wholeheartedly with you
> that adding
> special purpose methods are a bad idea.
>
> The problem is, in this case, the debate is not about *adding*
> anything, it
> is about *taking away* something that was already there, for a
> reason that
> is not *absolutely necessary* for the platform to progress.
>
> The fact that several relatively simple workarounds are available
> doesn't
> make up for the fact that previously good code will no longer
> compile, and a
> new class/trait/method will need to be created by the developer to
> make up
> for this feature being taken away from them, with no deprecation
> period or
> warning.
>
> IMHO, that is not the way to treat users of an up-and-coming platform.
>
> Thank you to all who took the time to participate in this discussion.
>
>
> bearfeeder wrote:
> >
> >
> > I strongly disagree with adding methods when they are special
> purpose. In
> > this case, it's perfectly validto create an Actor subclass as Philipp
> > suggested or to compose a class as I suggested. Forcing some "it
> works
> > sometimes and doesn't work other times" method onto a core class
> strikes
> > me
> > as a very bad path.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Actors-in-2.8-tp25064760p25086673.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>
>
>

Hi,

I'm a bit startled by the number of projects implementing more or less
sophisticated load-balancing schemes on top of actors, when there is a
perfectly fine and highly performant load-balancing task scheduler
doing it's job inside the actor framework. This looks like a lot of
duplicated effort and unnecessary complexity. So why not just submit
tasks to a task runner instead of going through another layer of
abstraction? My impression is that in a number of cases, this would
make programs more reliable and much more efficient.

- Tiark

On 20.08.2009, at 20:26, Paul LaCrosse wrote:

> Since all of the actor projects I've written use load-balancing on
> arrays of
> actors, which determine that the next message goes to the actor that
> currently has the fewest messages in their box, I'm biased towards
> believing
> that this ability is absolutely critical for high-performance actor
> applications.
>
> ;-)
>
>
>
> bearfeeder wrote:
>>
>> On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse
>> wrote:
>>
>>>
>>> Well, I'd like to suggest then that mailboxSize (or something
>>> similar
>>> that
>>> shows the pending message count) be part of the public API for
>>> Actors.
>>
>>
>> That would be a terrible idea in my opinion. The Mailbox size has
>> nothing
>> to do with sending a message. It's all about the implementation.
>> For
>> remote Actors, having a mailbox size would radically increase the
>> complexity
>> of the implementation. For Lift Actors, the materialization of the
>> mailbox
>> is done at message processing time to minimize the time in monitor.
>> Having
>> a mailbox count method publicly exposed would make that logic a ton
>> more
>> difficult. If your mailbox is an AMQP server someplace, there may
>> or may
>> not be a way of getting the mailbox size.
>>
>>
>>>
>>>
>>> I use it, to great effect, for load-balancing the submission of
>>> tasks to
>>> arrays of actors.
>>
>>
>> Then you can create:
>>
>> Actor with MyManagementStuff
>>
>> The MyManagementStuff would expose whatever management stuff you
>> needed,
>> but
>> it would be tied to the Actor implementation you've chosen and not
>> forced
>> on
>> every Actor implementor.
>>
>>
>>
>

Well, I tried that way first, and it did a terrible job of it.

Tiark Rompf wrote:
>
> Hi,
>
> I'm a bit startled by the number of projects implementing more or less
> sophisticated load-balancing schemes on top of actors, when there is a
> perfectly fine and highly performant load-balancing task scheduler
> doing it's job inside the actor framework. This looks like a lot of
> duplicated effort and unnecessary complexity. So why not just submit
> tasks to a task runner instead of going through another layer of
> abstraction? My impression is that in a number of cases, this would
> make programs more reliable and much more efficient.
>
> - Tiark
>
>
> On 20.08.2009, at 20:26, Paul LaCrosse wrote:
>
>> Since all of the actor projects I've written use load-balancing on
>> arrays of
>> actors, which determine that the next message goes to the actor that
>> currently has the fewest messages in their box, I'm biased towards
>> believing
>> that this ability is absolutely critical for high-performance actor
>> applications.
>>
>> ;-)
>>
>>
>>
>> bearfeeder wrote:
>>>
>>> On Thu, Aug 20, 2009 at 10:43 AM, Paul LaCrosse
>>> wrote:
>>>
>>>>
>>>> Well, I'd like to suggest then that mailboxSize (or something
>>>> similar
>>>> that
>>>> shows the pending message count) be part of the public API for
>>>> Actors.
>>>
>>>
>>> That would be a terrible idea in my opinion. The Mailbox size has
>>> nothing
>>> to do with sending a message. It's all about the implementation.
>>> For
>>> remote Actors, having a mailbox size would radically increase the
>>> complexity
>>> of the implementation. For Lift Actors, the materialization of the
>>> mailbox
>>> is done at message processing time to minimize the time in monitor.
>>> Having
>>> a mailbox count method publicly exposed would make that logic a ton
>>> more
>>> difficult. If your mailbox is an AMQP server someplace, there may
>>> or may
>>> not be a way of getting the mailbox size.
>>>
>>>
>>>>
>>>>
>>>> I use it, to great effect, for load-balancing the submission of
>>>> tasks to
>>>> arrays of actors.
>>>
>>>
>>> Then you can create:
>>>
>>> Actor with MyManagementStuff
>>>
>>> The MyManagementStuff would expose whatever management stuff you
>>> needed,
>>> but
>>> it would be tied to the Actor implementation you've chosen and not
>>> forced
>>> on
>>> every Actor implementor.
>>>
>>>
>>>
>>