Martin and Philipp,
My immediate problem is:

This has been a persistent problem with Scala Actors and I identified it
last year in November or December.

Philipp did the 2.7.4 release which did not address the issue.  The 2.7.5
release was supposed to address the issue, but the use of Lift Actors masked
the issue until the above issue was raised.  I left my 2.7.5 related
discussions with Philipp with the impression that the java.util.concurrent
library was being used for thread pooling rather than the FJ library.  On
this, I backed out the Lift Actor changes from powering Lift's CometActors
(Lift Actors power the long polling part of Lift).

On Wed, Sep 30, 2009 at 8:18 AM, martin <> wrote:

> About actors in Scala 2.8:
>  . they have been refactored substantially compared to what's in the
>   2.7.x branch
>  . Philipp has sent mails about this to scala-internals (05/31)
>  . Philipp has invited DPP to look at the refactorings in 2.8 (07/21)
> to which
>   he responded positively.

I responded politely.  Granted this is not something I always do (note, I am
not being facetious), but I simply said something like "looks good to me."

>  . The ForkJoinPool in 2.8 is completely different from FJTask in
>   2.7.5; it's the version that's going into JDK7. It has been
>   battle-tested and should not suffer from any memory leaks.

> The reason why Scala actors use the FJ framework is performance, in
> particular on multi-core hardware. So we do not think it's a good idea
> to go back to java.util.concurrent, except maybe for applications with
> very specialized demands.

Do you have specific benchmarks that justify the tradeoff of baking in an
external library (that could be as buggy as the one that's currently baked
into Scala) versus java.util.concurrent?

> We think the main problem was that lift depends on Scala 2.7.x, and
> that the actor refactorings have not gone into the 2.7.x branch.

I did a code review of the 2.8 Actors.  I am not convinced that Erik's
meta-concerns were addressed.  I will be happy to be more descriptive

> The
> result is that people have not noticed the changes. For example, most
> of the issues that Erik raises in his blog post no longer apply to
> Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken
> much longer than we have foreseen, because some of the problems were
> harder than initially thought. We are sorry to have left the 2.7
> branch relatively unattended for so long. It's difficult for us,
> though, to provide the resources to support two diverging branches in
> parallel. More community support with backports etc could help.

While this is a nice thought, given the choice between debating with EPFL as
to whether my changes are good enough or doing a Lift Actor implementation,
I will opt for continuing to develop and maintain the Lift Actor library.
 This gives Lift users the assurance that bugs will be fixed in a timely
manner, that we can add features based on community need, and that we can
work with other library authors to insure common interfaces.

> To fix the concrete issue at hand, we replaced FJTask with (a backport
> of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch,
> to be released as 2.7.7. That takes care of the memory leaks in
> FJTask.
> Now to the larger picture. We are not at all wedded to Scala actors
> here; after all it's just a library. If there are others which fulfill
> some needs better, great! But we have to be honest to avoid confusion.
> One of the main differences between Scala actors and lift actors and
> Akka seems to be that only Scala actors provide nested receives, so
> only Scala actors really let you avoid an inversion of control.

Lift Actors allow for changing (and nesting) the message handler on a
message-by-message basis and because the handler can be defined within a
given partial function, it can close over the variables visible in that
partial function.  Granted the syntax for doing so in Scala Actors is much
more pleasing, the functionality exists with Lift Actors.

> This
> is a feature which complicates the implementation considerably, and
> that's what all our main results are about. You might not care about
> this particular feature in your code, and consequently you might
> choose a different abstraction. But calling that abstraction simply
> `actors' causes unnecessary confusion, in our opinion.

Quoting from Wikipedia <>:

An actor is a computational entity that, in response to a message it
receives, can concurrently:

   - send a finite number of messages to other actors;
      - create a finite number of new actors;
      - designate the behavior to be used for the next message it receives.

Lift Actors do all of these things.

I think it's a great thing that Philipp and the EPFL team introduced Actors
to the JVM and Scala world.  I think the publications that you guys have
written are nothing short of inspiring.

But there is a difference between a research vehicle and something that can
be used in production systems.  What Philipp has done is delivered a
prototype and a vision of concurrency to the Scala community.  What Jonas
and I have done is built production-quality systems based on that vision,
our experience, and other systems we have used or observed.

I would much prefer to free Philipp to do his pi calculus work (or whatever
else inspires him) than maintain a library for me.  I want to see the next
great thing he comes up with rather than making him my bug-fixing slave.



> And that's not
> good for the goal of convincing people that actors are a useful
> concurrency abstraction. So, nothing against lift actors and Akka, but
> we need to be precise about the tradeoffs. Maybe call them `flat
> actors' or something like that.

> Martin and Philipp
> >

Lift, the simply functional web framework
Beginning Scala
Follow me:
Surf the harmonics

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to