David, I concur that while progress has been made my meta-issues have not been addressed. I think that effectively addressing using the current model and retaining something resembling API compatibility would be a huge task, and probably would have meant that very little newness from a feature-functionality could have been included in Scala 2.8.
-Erik On Thu, Oct 1, 2009 at 8:34 PM, David Pollak <feeder.of.the.be...@gmail.com>wrote: > Martin and Philipp, > My immediate problem is: > > http://groups.google.com/group/liftweb/browse_thread/thread/b3783e24b8417521/f89548ba1fa70319?hl=en&lnk=gst&q=oome# > > 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 <oder...@gmail.com> 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 > off-list. > > >> 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 <http://en.wikipedia.org/wiki/Actor_model>: > > 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. > > Thanks, > > David > > > >> 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 http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > > > -- http://erikengbrecht.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
