Quantcast

Should Scala's native actors library be marked obsolete.

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Should Scala's native actors library be marked obsolete.

Sadek Drobi
It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?

I really think we should either fix it, or replace it.

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Hanns Holger Rutz
Messagetwo reasons, why i think this is no solution
- akka is a large system, too large for the standard lib
- it runs a "microkernel" and needs external config files,
  i don't see why you would want that for simple applications others than servers
- it heavily relies on java libraries which make it probably a bad choice if scala
  is going to be more VM independant ; if you look at building-akka, you
  see at least four dozens java library dependancies.

since the API of scala-actors is simple and lightweight enough, i would say the far better
solution is to fix the problems in scala-actors. i don't know how buggy it is, but for the
simple cases i have been using it, i had no problems. the only problem i ever encountered
is that the threads starve when you run blocking IO in an actor.

of course, scala-actors also relies heavily on java, namely java-concurrent, but this is
part of java SE and no extra jars are required.

the only other possible way is to move the scala-actors completely out of scala standard
dist. but then i think it is small enough that it is good to have it ready at hand.

i personally find scala-swing more a candidate for asking why this should be part of
the standard dist. i find its API absolutely non appealing, and there will be the same
problem when scala goes to other VMs. for example, i guess scala-actors compile
fine on android, why swing obviously does not.

best, -sciss-



----- original message --------

Subject: [scala-user] Should Scala's native actors library be marked obsolete.
Sent: Sat, 15 Jan 2011
From: Sadek Drobi

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?

I really think we should either fix it, or replace it.

Sadek

--
www.sadekdrobi.com
?do??u?


--- original message end ----
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Ray Racine
In reply to this post by Sadek Drobi
Wowa .. sheath your sword their D'Artagnan.  I don't think they were abandoned as some major work was certainly done on them for 2.8.  As far as full of memory leaks, I use Scala's actors.  In one particular case I have a "clock" Actor which in turn sends periodic events to other actors.  The periodicity is such I have actors reactively responding on events firing in the seconds range.  My servers are up for weeks at a time under load.  I am unaware of any current memory leak issues.

I don't grok "full of runtime exceptions".   So I'll just whiff a red cape on that one as it goes by.

Bad documentation.  Well certainly the documentation is "terse" and think the wold certainly could use a "booklet" with examples patterns and use cases on using Scala Actors.  

Interesting and a positive sign that you view the Collections library as clean.  There is a different group of sword swinging, pick fork and torch carriers that hold regular chant session on how the new Collections library was essentially an act of language suicide.  Really?

Nothing is perfect, but the vast majority of Collection/Actor mud slinging is frustration from a lack of understanding and to the difficulty in grasping the reactive asynch'ness of actors and how to apply those concepts to algorithms which most programmers have spent their careers studying, hacking and solving using imperative code.


On Sat, Jan 15, 2011 at 11:11 AM, Sadek Drobi <[hidden email]> wrote:
It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?

I really think we should either fix it, or replace it.

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ



--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Erik Engbrecht
We can be objective about this...

That's not a particularly long list (and a couple of them aren't about actors).

I think one of the big issues with Scala Actors is that they use a ton of abstraction it can be difficult to distinguish among bugs in user code, incorrect configuration, intentional design limitations, and bugs in the library.  This is confounded by the fact that barrier to initial usage of Scala actors is roughly zero (hence it attracts a lot of idle exploration - not a bad thing), concurrent code is fundamentally difficult even with actors (but people often mistake them for magic), Scala actors can be used with zero configuration (so it's not obvious that a "bug" may be due to misconfiguring the scheduler), and the design limitations are mostly undocumented.

In short, I think people can very quickly run through the first few phases of the hype cycle and get stuck in the trough of disillusionment when the magic fades and they start experiencing issues.

I also suspect the library is suffering from a degree of abandonment by serious users, now that Lift has its own lightweight actors and Akka is around for people who are prepared to go to a little more effort to get things setup and introduce some more dependencies.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

HamsterofDeath
In reply to this post by Ray Racine
i heard rumors about such people. what are they thinking? they should be
forced to use only java collections for a week!

Am 15.01.2011 18:06, schrieb Ray Racine:
> Interesting and a positive sign that you view the Collections library
> as clean.  There is a different group of sword swinging, pick fork and
> torch carriers that hold regular chant session on how the new
> Collections library was essentially an act of language suicide.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

√iktor Ҡlang
In reply to this post by Hanns Holger Rutz
Hey guys,

I just saw some factual mistakes and thought I ought to clear that up.

On Sat, Jan 15, 2011 at 6:00 PM, Sc iss <[hidden email]> wrote:
two reasons, why i think this is no solution
- akka is a large system, too large for the standard lib

With the Akka 1.0-RCs, the core part of Akka is really small, with something like 5 small external deps, that could be reduced to 0 with some work.
 
- it runs a "microkernel" and needs external config files,

The microkernel is the "full" package and is just one way of using Akka, also, starting with the 1.0 RCs you have sensible defaults for all of the Akka config, so any external file is not mandatory. You can also tap into the config and declare it programmatically in your app.
 
 i don't see why you would want that for simple applications others than servers
- it heavily relies on java libraries which make it probably a bad choice if scala
 is going to be more VM independant ; if you look at building-akka, you
 see at least four dozens java library dependancies.

since the API of scala-actors is simple and lightweight enough, i would say the far better
solution is to fix the problems in scala-actors. i don't know how buggy it is, but for the
simple cases i have been using it, i had no problems. the only problem i ever encountered
is that the threads starve when you run blocking IO in an actor.

of course, scala-actors also relies heavily on java, namely java-concurrent, but this is
part of java SE and no extra jars are required.

the only other possible way is to move the scala-actors completely out of scala standard
dist. but then i think it is small enough that it is good to have it ready at hand.

i personally find scala-swing more a candidate for asking why this should be part of
the standard dist. i find its API absolutely non appealing, and there will be the same
problem when scala goes to other VMs. for example, i guess scala-actors compile
fine on android, why swing obviously does not.

best, -sciss-



----- original message --------

Subject: [scala-user] Should Scala's native actors library be marked obsolete.
Sent: Sat, 15 Jan 2011
From: Sadek Drobi

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. Two problems there:If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.If AKKA is the way to go, why not integrate it into the distribution?
I really think we should either fix it, or replace it.
Sadek

--
www.sadekdrobi.com
?do??u?


--- original message end ----



--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Donna Malayeri
In reply to this post by Sadek Drobi
My suggestion: when you find a memory leak or runtime exception that you're sure is a bug, file a ticket or post a specific stack trace here. If the library is in fact so buggy (which I doubt), the maintainers are not aware of this.

Donna

On Sat, Jan 15, 2011 at 5:11 PM, Sadek Drobi <[hidden email]> wrote:
It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

David Crosson
In reply to this post by Sadek Drobi
Didn't agree with you at all, I'm quite new to both scala and actors API.

I've just finished a complex distributed algorithm using scala actors, more than 65000 actors in a typical session, and it runs fine with very good performances (I couldn't believe it first). But of course, I had to manage well the messages flows between actors in order to avoid memory leak.

About Akka, looks very insteresting, but don't know if it is possible to just use standard scala actors API, and using external configuration (parameters) change transparently the implementation to use akka instead of scala default one ? Of course, without having to recompile my application.

David.


2011/1/15 Sadek Drobi <[hidden email]>
It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?

I really think we should either fix it, or replace it.

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

√iktor Ҡlang


On Mon, Jan 17, 2011 at 2:16 PM, David Crosson <[hidden email]> wrote:
Didn't agree with you at all, I'm quite new to both scala and actors API.

I've just finished a complex distributed algorithm using scala actors, more than 65000 actors in a typical session, and it runs fine with very good performances (I couldn't believe it first). But of course, I had to manage well the messages flows between actors in order to avoid memory leak.

About Akka, looks very insteresting, but don't know if it is possible to just use standard scala actors API, and using external configuration (parameters) change transparently the implementation to use akka instead of scala default one ? Of course, without having to recompile my application.

No, that's currently not possible. They have different philosophies in certain areas, please see this comparison between 4 different actor implementations for Scala: http://klangism.tumblr.com/post/2497057136/all-actors-in-scala-compared
 

David.


2011/1/15 Sadek Drobi <[hidden email]>

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?

I really think we should either fix it, or replace it.

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ




--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Josh Suereth
To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.

** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.

actor {
   react { 
     case Push(data) =>
        react {
           case Pop =>  reply(data)
        }
     }
   }
}

(at least I think I got that right).   Basically, this actor changes its 'handler' message based on what messages it has recently received.  After receiving a Push message, it looks in its queue for the first pop and replies to that with the data from the push method.  

In any case, you can see why nested messages can be considered dangerous.  If you have some sort of race condition such that the nested messages do not show up as expected, an Actor can fill up its queues quickly.  Akka specifically disallows this usage to prevent that type of bug (and to improve its own performance).  Scala actors enabled it but the onus is on you the developer to ensure a correct program.

** The second thing the standard library does is allow actors to send messages to 'threads'.  That is, if I have the following actor:

val replies = actor {
   react {
     case x => reply(x)
  }
}

And I write the following code *not* within an actor:   replies ! "somemsg"    The response goes to an actor.   However since I sent the message not from any particular actor, the message is placed into a thread-local actor for the thread where 'replies ! "somemsg"' was called.  This ThreadLocal can be used to obtain replies and such.  However, ThreadLocals are prone to memory leaks, and the Scala core library defines its own actor garbage collector to try to clean these actors.   Ideally, the number of these thread locals should be small in a program, however for certain programs it may be large and the performance of this new GC becomes a factor you need to tune and tweak.

My normal "scala core actor" application usually has just a single thread that's sending messages into actors, so this is not a big issue, but it is an additional layer of complexity one must worry about.  The alternative here is to require users to assign an actor to handle responses for every call.  The Scala actors library went for 'very expressive' here.  

So basically, there are a few 'rough edges' to the library, where rough means one must be cautious when using these features.   The library itself is very expressive and easy to use, so it's somewhat deceptive to users that these issues could be lingering in the corners.   It's also not something once can pin on the library, besides saying that it's 'too expressive' or 'too unrestricted'.

IMHO, the scala actors library is create for small-medium sized projects.  The remote/distribution story wasn't the best the last time I tried, so I'd used Akka for any large system, but I'd also say that the core library actors serve a purpose.

I hope that perspective helps.  As stated before, the onus is on the user to wield the power correctly.
   

On Mon, Jan 17, 2011 at 8:39 AM, √iktor Klang <[hidden email]> wrote:


On Mon, Jan 17, 2011 at 2:16 PM, David Crosson <[hidden email]> wrote:
Didn't agree with you at all, I'm quite new to both scala and actors API.

I've just finished a complex distributed algorithm using scala actors, more than 65000 actors in a typical session, and it runs fine with very good performances (I couldn't believe it first). But of course, I had to manage well the messages flows between actors in order to avoid memory leak.

About Akka, looks very insteresting, but don't know if it is possible to just use standard scala actors API, and using external configuration (parameters) change transparently the implementation to use akka instead of scala default one ? Of course, without having to recompile my application.

No, that's currently not possible. They have different philosophies in certain areas, please see this comparison between 4 different actor implementations for Scala: http://klangism.tumblr.com/post/2497057136/all-actors-in-scala-compared
 

David.


2011/1/15 Sadek Drobi <[hidden email]>

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA. 
Two problems there:
If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.
If AKKA is the way to go, why not integrate it into the distribution?

I really think we should either fix it, or replace it.

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ




--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Should Scala's native actors library be marked obsolete.

Chris Marshall
That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  


From: [hidden email]
Date: Mon, 17 Jan 2011 09:27:11 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: [hidden email]
CC: [hidden email]; [hidden email]; [hidden email]

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.

** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.

actor {
   react { 
     case Push(data) =>
        react {
           case Pop =>  reply(data)
        }
     }
   }
}


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Rex Kerr-2
Makes sense to me.  If you say "Pop" you mean, "give me the next available item".  If none are available you won't hear back around until someone sends it a Push.  (That's presumably what you'd want from an actor-based queue anyway, isn't it?)

I think it's quite ingenious, actually, to play with the message buffer that way.

  --Rex

On Mon, Jan 17, 2011 at 1:16 PM, Chris Marshall <[hidden email]> wrote:
That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  


From: [hidden email]
Date: Mon, 17 Jan 2011 09:27:11 -0500

Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: [hidden email]
CC: [hidden email]; [hidden email]; [hidden email]


To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.

** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.

actor {
   react { 
     case Push(data) =>
        react {
           case Pop =>  reply(data)
        }
     }
   }
}



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Should Scala's native actors library be marked obsolete.

Chris Marshall
If you say so: I'd expect that popping an element off an empty queue gave me nothing: I would expect to have to poll if I was prepared to wait. That's just the Java speaking I suppose.

Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>

Chris


Date: Mon, 17 Jan 2011 13:33:21 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
From: [hidden email]
To: [hidden email]
CC: [hidden email]

Makes sense to me.  If you say "Pop" you mean, "give me the next available item".  If none are available you won't hear back around until someone sends it a Push.  (That's presumably what you'd want from an actor-based queue anyway, isn't it?)

I think it's quite ingenious, actually, to play with the message buffer that way.

  --Rex


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Should Scala's native actors library be marked obsolete.

Chris Marshall
I should say that the sarcasm contained herein is completely unrepresentative of my opinions on Philip's work with the standard library. I have a ton of actor-based processes here and the nested-react functionality is a "killer app" as far as I am concerned (that and the fact that Akka still hasn't released a 1.0 final). I have also found it to be reliable and stable - I have not experienced any of the problems that the OP talked about.

The scala actors library is most certainly not obsolete.

Chris


From: [hidden email]
To: [hidden email]
CC: [hidden email]
Subject: RE: [scala-user] Should Scala's native actors library be marked obsolete.
Date: Mon, 17 Jan 2011 18:37:07 +0000

If you say so: I'd expect that popping an element off an empty queue gave me nothing: I would expect to have to poll if I was prepared to wait. That's just the Java speaking I suppose.

Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>

Chris


Date: Mon, 17 Jan 2011 13:33:21 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
From: [hidden email]
To: [hidden email]
CC: [hidden email]

Makes sense to me.  If you say "Pop" you mean, "give me the next available item".  If none are available you won't hear back around until someone sends it a Push.  (That's presumably what you'd want from an actor-based queue anyway, isn't it?)

I think it's quite ingenious, actually, to play with the message buffer that way.

  --Rex


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Rex Kerr-2
In reply to this post by Chris Marshall
On Mon, Jan 17, 2011 at 1:37 PM, Chris Marshall <[hidden email]> wrote:
Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>

Maybe I meant elegant; it's a code snippet that in hindsight is obvious, but my first instinct to create a non-blocking queue would not have gone that way.  I probably would have thought of some sort of polling solution which would be more effort and probably less efficient.  It also nicely shows off the power of nested react statements (in that you have a queue of futures for free, and also highlights that consuming only part of the mailbox can be useful).

  --Rex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Josh Suereth
@Chris - The code is not correct, however you are right.  I should have made the message be "Poll" instead of "Pop".  I also agree with you that you're using a queue to reimplement a queue.  However, it does give a different style of operation, in that you can make the call to Pop/Poll be asynchronous and non-blocking of the current thread.   *that* is the innovative part and the key reason to use actors (if your problem can be model as such).

This simple example shows the power of the standard actors library.  That was the point.  My other point was that it's somewhat easy to create a situation where a message queue will fill up and not be processed, especially if things get complex.  This gives the appearance of the Scala actors library being more flawed than it is.   

The biggest concern I have with the actors library is that of configurability for production.  I believe the library has lots of abstraction points where I can do what I need to do to make it perform as optimital as its design allows, however these are not well documented, nor is it intuitive what needs to be configured.   For example, GC configuration is critical in any large-scale JVM deployment.  This means we need to configure the ActorsGC and the GC for optimal performance with each other.  I'd say that actors library is tuned for most situations you'd run at it.   However, as stated before, if I was doing a large-scale system I'd probably use Akka, as its designed is focused on this use case.  Its configuration is well documented, and there is a performance edge because they do not allow nested messages.

Again, the point being that you can express more powerful concepts in Scala's actors library, but you must be careful with that power.


On Mon, Jan 17, 2011 at 2:16 PM, Rex Kerr <[hidden email]> wrote:
On Mon, Jan 17, 2011 at 1:37 PM, Chris Marshall <[hidden email]> wrote:
Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>

Maybe I meant elegant; it's a code snippet that in hindsight is obvious, but my first instinct to create a non-blocking queue would not have gone that way.  I probably would have thought of some sort of polling solution which would be more effort and probably less efficient.  It also nicely shows off the power of nested react statements (in that you have a queue of futures for free, and also highlights that consuming only part of the mailbox can be useful).

  --Rex


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Should Scala's native actors library be marked obsolete.

Chris Marshall
I'd be interested to see a blog entry about configuring the scala actors library (and tuning for GC etc) as you are right; there is little or no documentation on it.


From: [hidden email]
Date: Mon, 17 Jan 2011 17:23:10 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: [hidden email]
CC: [hidden email]; [hidden email]

The biggest concern I have with the actors library is that of configurability for production.  I believe the library has lots of abstraction points where I can do what I need to do to make it perform as optimital as its design allows, however these are not well documented, nor is it intuitive what needs to be configured.   For example, GC configuration is critical in any large-scale JVM deployment.  This means we need to configure the ActorsGC and the GC for optimal performance with each other.  I'd say that actors library is tuned for most situations you'd run at it.   However, as stated before, if I was doing a large-scale system I'd probably use Akka, as its designed is focused on this use case.  Its configuration is well documented, and there is a performance edge because they do not allow nested messages.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Daniel Sobral
In reply to this post by Chris Marshall
Actually, it can be used for synchronization algorithms in an interesting way:

case class Put(data: Any)
case object Get
actor {
  react {
    case Put(data) => react {
      case Get => reply(data)
    }
    case Get => val replyTo = sender; react {
      case Put(data) => replyTo ! data
    }
  }
}

A Stack can be written recursively:

case class Push(data: Any)
case object Pop
val stack = actor {
  def recurse(data: Any) {
    var popped = false
    loopWhile(!popped) {
      react {
        case Push(data) => recurse(data)
        case Pop => reply(data); popped = true
        case _ => // ignore
      }
    }
  }
  loop {
    react {
      case Push(data) => recurse(data)
    }
  }
}

It does not guarantee ordering when multiple clients are pushing/popping, but it does, otherwise, work.


On Mon, Jan 17, 2011 at 16:16, Chris Marshall <[hidden email]> wrote:
That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  


From: [hidden email]
Date: Mon, 17 Jan 2011 09:27:11 -0500

Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: [hidden email]
CC: [hidden email]; [hidden email]; [hidden email]


To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.

** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.

actor {
   react { 
     case Push(data) =>
        react {
           case Pop =>  reply(data)
        }
     }
   }
}





--
Daniel C. Sobral

I travel to the future all the time.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Ray Racine
When I've used nesting it has been to implement an Actor as a state machine.  New State, different set of messages it will respond to or ignore.  Obviously any FSM beyond a simple sequencing falls apart with this approach.  But then again almost anything I attempted to do with an Actor is by definition a first time for me and an experimental approach and usage.    The standout example in my code has to to do with file polling / fetching / processing etc.

On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral <[hidden email]> wrote:
Actually, it can be used for synchronization algorithms in an interesting way:

case class Put(data: Any)
case object Get
actor {
  react {
    case Put(data) => react {
      case Get => reply(data)
    }
    case Get => val replyTo = sender; react {
      case Put(data) => replyTo ! data
    }
  }
}

A Stack can be written recursively:

case class Push(data: Any)
case object Pop
val stack = actor {
  def recurse(data: Any) {
    var popped = false
    loopWhile(!popped) {
      react {
        case Push(data) => recurse(data)
        case Pop => reply(data); popped = true
        case _ => // ignore
      }
    }
  }
  loop {
    react {
      case Push(data) => recurse(data)
    }
  }
}

It does not guarantee ordering when multiple clients are pushing/popping, but it does, otherwise, work.


On Mon, Jan 17, 2011 at 16:16, Chris Marshall <[hidden email]> wrote:
That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.   Date: Mon, 17 Jan 2011 09:27:11 -0500

Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: [hidden email]
CC: [hidden email]; [hidden email]; [hidden email]


To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.

** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.

actor {
   react { 
     case Push(data) =>
        react {
           case Pop =>  reply(data)
        }
     }
   }
}





--
Daniel C. Sobral

I travel to the future all the time.



--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should Scala's native actors library be marked obsolete.

Jonas Bonér-4
Akka has 'become' which hotswaps the message handler. IMHO cleaner way
than nested receives.
Docs here: http://doc.akka.io/actors-scala#Actors%20(Scala)-HotSwap

It can be used for f.e. building an FSM. See this example of Dining
Philosophers:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/src/main/scala/DiningHakkersOnBecome.scala#

Akka also has a FSM DSL. Here is the same problem solved using this the DSL:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/src/main/scala/DiningHakkersOnFsm.scala#L1

/Jonas

On 19 January 2011 16:26, Ray Racine <[hidden email]> wrote:

> When I've used nesting it has been to implement an Actor as a state machine.
>  New State, different set of messages it will respond to or ignore.
>  Obviously any FSM beyond a simple sequencing falls apart with this
> approach.  But then again almost anything I attempted to do with an Actor is
> by definition a first time for me and an experimental approach and usage.
>  The standout example in my code has to to do with file polling / fetching /
> processing etc.
>
> On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral <[hidden email]> wrote:
>>
>> Actually, it can be used for synchronization algorithms in an interesting
>> way:
>>
>> case class Put(data: Any)
>> case object Get
>> actor {
>>   react {
>>     case Put(data) => react {
>>       case Get => reply(data)
>>     }
>>     case Get => val replyTo = sender; react {
>>       case Put(data) => replyTo ! data
>>     }
>>   }
>> }
>>
>> A Stack can be written recursively:
>>
>> case class Push(data: Any)
>> case object Pop
>> val stack = actor {
>>   def recurse(data: Any) {
>>     var popped = false
>>     loopWhile(!popped) {
>>       react {
>>         case Push(data) => recurse(data)
>>         case Pop => reply(data); popped = true
>>         case _ => // ignore
>>       }
>>     }
>>   }
>>   loop {
>>     react {
>>       case Push(data) => recurse(data)
>>     }
>>   }
>> }
>>
>> It does not guarantee ordering when multiple clients are pushing/popping,
>> but it does, otherwise, work.
>>
>>
>> On Mon, Jan 17, 2011 at 16:16, Chris Marshall <[hidden email]>
>> wrote:
>>>
>>> That "queue" behaves very oddly if you call pop() before anyone has
>>> enqueued anything (al least in my opinion). Also you are missing a loop.
>>>
>>> ________________________________
>>> From: [hidden email]
>>> Date: Mon, 17 Jan 2011 09:27:11 -0500
>>> Subject: Re: [scala-user] Should Scala's native actors library be marked
>>> obsolete.
>>> To: [hidden email]
>>> CC: [hidden email]; [hidden email];
>>> [hidden email]
>>>
>>> To me, there are two things the scala core library does that make it both
>>> (1) scary and (2) powerful.
>>> ** The first is that is supports nested receive/react calls.  These can
>>> be used to create really interesting programs, such as Phillip Haller's
>>> example of a queue.
>>> actor {
>>>    react {
>>>      case Push(data) =>
>>>         react {
>>>            case Pop =>  reply(data)
>>>         }
>>>      }
>>>    }
>>> }
>>>
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>
>
> --
> The object of life is not to be on the side of the majority, but to escape
> finding oneself in the ranks of the insane. - Marcus Aurelius
>



--
Jonas Bonér

Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
blog: http://jonasboner.com
twtr: @jboner
123
Loading...