Re: Re: design goals of actors library

Miles,  I don't think David's model is fundamentally incompatible with Scala's actor model.  I actually think a little rationalization of the OutputChannel -> AbstractActor -> Actor hierarchy could actually let him plug below AbstractActor and have full interoperability with scala.actors.Actor.  Most of what's in scala.actors.Actor (the trait and the object) is there to provide a very rich and expressive set of methods with which to build actors.  That expressiveness leads to a high level of complexity and a few nasty edge conditions because it severely limits the assumptions that the library can make about what code an actor actually contains.  David's model brings that expressiveness way down and thus eliminates the complexity down to an event loop based on a partial function for matching and processing messages.
-Erik
On Fri, May 22, 2009 at 4:49 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, May 22, 2009 at 10:42 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> I'm not sure if this is anything different than what I understand the Erlang
> Actor model formerly the Scheme Actor model to be... asynchronous message
> handling.
>
> I think the Scala Actors have become something more than the original Actor
> model.

Perhaps. But Scala already has something commonly known as "Scala
Actors" as part of it's standard library. Introducing another
partially overlapping abstraction with a very similar name seems
likely to cause confusion.

Why not call it the Lift Workqueue or something like that?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://twitter.com/milessabin

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

On Fri, May 22, 2009 at 10:58 PM, Erik Engbrecht
wrote:
>   I don't think David's model is fundamentally incompatible with Scala's
> actor model.  I actually think a little rationalization of the OutputChannel
> -> AbstractActor -> Actor hierarchy could actually let him plug below
> AbstractActor and have full interoperability with scala.actors.Actor.

That would be very welcome ...

The standard library benefits Scala's entire user community, so if
there are any spare cycles I'd like to see them spent on improving
that.

Cheers,

Miles

On Fri, May 22, 2009 at 2:03 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, May 22, 2009 at 10:58 PM, Erik Engbrecht
<erik.engbrecht@gmail.com> wrote:
>   I don't think David's model is fundamentally incompatible with Scala's
> actor model.  I actually think a little rationalization of the OutputChannel
> -> AbstractActor -> Actor hierarchy could actually let him plug below
> AbstractActor and have full interoperability with scala.actors.Actor.

That would be very welcome ...

The standard library benefits Scala's entire user community, so if
there are any spare cycles I'd like to see them spent on improving
that.

OutputChannel is the root of the problem:

abstract def send (msg : Msg, replyTo : OutputChannel[Any]) : Unit Sends msg to this OutputChannel (asynchronous) supplying explicit reply destination.

The complexity in the Actor library starts there.  This single method implies that everything that sends a message must be an Actor (or at least an OutputChannel.)  This means ThreadLocal actors.  ThreadLocal Actors mean ActorGC and/or Proxies.  ActorGC means memory problems.

I am all for standard code bases and the Lift code base is available to all under a license very similar to the Scala license.  Further, I'm perfectly happy for my work to make it back into the Scala distribution.  However, the spent costs of working around issues in a code base that I don't control that comes out of a schedule that I don't control means that what's best for Lift-based applications is to write a simple Actor model.

So, why do I call it Actors?  Because the phrase has a particular meaning and resonates well with people who are taking a first look at Scala and/or Lift.  If I say, "Lift's comet support with built on a workpile system" it has a lot less meaning and value to the listener than "Lift's comet support is built on Actors".  So, Lift's Comet support will continue to live on top of Actors, but the implementation of those Actors is one that's better suited to the needs of web apps.

Thanks,

David

 

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://twitter.com/milessabin

--
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

David,  Do you have any automated tests that you could share for reproducing the problems you're seeing?  They would be very helpful.
-Erik

On Fri, May 22, 2009 at 6:00 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Fri, May 22, 2009 at 2:03 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, May 22, 2009 at 10:58 PM, Erik Engbrecht
<erik.engbrecht@gmail.com> wrote:
>   I don't think David's model is fundamentally incompatible with Scala's
> actor model.  I actually think a little rationalization of the OutputChannel
> -> AbstractActor -> Actor hierarchy could actually let him plug below
> AbstractActor and have full interoperability with scala.actors.Actor.

That would be very welcome ...

The standard library benefits Scala's entire user community, so if
there are any spare cycles I'd like to see them spent on improving
that.

OutputChannel is the root of the problem:

abstract def send (msg : Msg, replyTo : OutputChannel[Any]) : Unit Sends msg to this OutputChannel (asynchronous) supplying explicit reply destination.

The complexity in the Actor library starts there.  This single method implies that everything that sends a message must be an Actor (or at least an OutputChannel.)  This means ThreadLocal actors.  ThreadLocal Actors mean ActorGC and/or Proxies.  ActorGC means memory problems.

I am all for standard code bases and the Lift code base is available to all under a license very similar to the Scala license.  Further, I'm perfectly happy for my work to make it back into the Scala distribution.  However, the spent costs of working around issues in a code base that I don't control that comes out of a schedule that I don't control means that what's best for Lift-based applications is to write a simple Actor model.

So, why do I call it Actors?  Because the phrase has a particular meaning and resonates well with people who are taking a first look at Scala and/or Lift.  If I say, "Lift's comet support with built on a workpile system" it has a lot less meaning and value to the listener than "Lift's comet support is built on Actors".  So, Lift's Comet support will continue to live on top of Actors, but the implementation of those Actors is one that's better suited to the needs of web apps.

Thanks,

David

 

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://twitter.com/milessabin

--
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

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

On Fri, May 22, 2009 at 4:55 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

David,  Do you have any automated tests that you could share for reproducing the problems you're seeing?  They would be very helpful.

Unfortunately, no.

I have reproduced the memory retention issues primarily in live running code on public sites (e.g., http://demo.liftweb.net)  I hook YourKit up to the running instance, wait a bunch of hours and see where memory is retained.

The deadlock issues (e.g., bug 2003) are spurious and seem to only happen on my Intel 920 machine (4 cores, each hyperthreaded) running Ubuntu 9.04, but not in my core 2 duo laptop.  This seems to be the nature of timing-related issues.

So, the problems that I've experienced are production problems or problems that randomly surface on my development box.  The one memory retention reproduction that I sent to Philipp can be avoided if one does not put too much pressure on the JVM's memory system.

Sorry.

David

 

-Erik

On Fri, May 22, 2009 at 6:00 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Fri, May 22, 2009 at 2:03 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, May 22, 2009 at 10:58 PM, Erik Engbrecht
<erik.engbrecht@gmail.com> wrote:
>   I don't think David's model is fundamentally incompatible with Scala's
> actor model.  I actually think a little rationalization of the OutputChannel
> -> AbstractActor -> Actor hierarchy could actually let him plug below
> AbstractActor and have full interoperability with scala.actors.Actor.

That would be very welcome ...

The standard library benefits Scala's entire user community, so if
there are any spare cycles I'd like to see them spent on improving
that.

OutputChannel is the root of the problem:

abstract def send (msg : Msg, replyTo : OutputChannel[Any]) : Unit Sends msg to this OutputChannel (asynchronous) supplying explicit reply destination.

The complexity in the Actor library starts there.  This single method implies that everything that sends a message must be an Actor (or at least an OutputChannel.)  This means ThreadLocal actors.  ThreadLocal Actors mean ActorGC and/or Proxies.  ActorGC means memory problems.

I am all for standard code bases and the Lift code base is available to all under a license very similar to the Scala license.  Further, I'm perfectly happy for my work to make it back into the Scala distribution.  However, the spent costs of working around issues in a code base that I don't control that comes out of a schedule that I don't control means that what's best for Lift-based applications is to write a simple Actor model.

So, why do I call it Actors?  Because the phrase has a particular meaning and resonates well with people who are taking a first look at Scala and/or Lift.  If I say, "Lift's comet support with built on a workpile system" it has a lot less meaning and value to the listener than "Lift's comet support is built on Actors".  So, Lift's Comet support will continue to live on top of Actors, but the implementation of those Actors is one that's better suited to the needs of web apps.

Thanks,

David

 

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://twitter.com/milessabin

--
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

--
http://erikengbrecht.blogspot.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