InterruptedExceptions with actors.Futures.future

Looks like a bug.  Somehow you are catching the Actor killing itself when complete (by using Actor.exit).  I believe it sends itself the exception to shut itself down, but I don't recall the details.
If you just want to use Futures (and not actors), why not try java.util.concurrent?   If you need respond and friends, why not try scalaz.concurrent.Promise, which is fully monadic and awesome.
- Josh

On Sun, Apr 24, 2011 at 5:35 PM, Andreas Flierl <asflierl [at] googlemail [dot] com> wrote:

Hi,

does anybody have an idea why I get InterruptedExceptions (and a
return value of SuspendActorControl) in the following REPL session?


Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server
VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import actors.Futures.future
import actors.Futures.future

scala> def f = (1 to 1000000) map (_.toString) length
f: Int

scala> future(f)()
res0: Int = 1000000

scala> future(f) foreach println
1000000
scala.actors.ActorProxy@34feb215: caught
java.lang.InterruptedException
java.lang.InterruptedException
       at scala.actors.ActorProxy.exit(ActorProxy.scala:32)
       at scala.actors.Reactor$$anonfun$2.apply(Reactor.scala:267)
       at scala.actors.Reactor$$anonfun$2.apply(Reactor.scala:267)
       at scala.Function0$class.apply$mcV$sp(Function0.scala:39)
       at scala.runtime.AbstractFunction0.apply$mcV
$sp(AbstractFunction0.scala:17)
       at scala.actors.ReactorTask.run(ReactorTask.scala:44)
       at scala.actors.Reactor$class.resumeReceiver(Reactor.scala:129)
       at scala.actors.ActorProxy.scala$actors$ReplyReactor$$super
$resumeReceiver(ActorProxy.scala:20)
       at scala.actors.ReplyReactor$class.resumeReceiver(ReplyReactor.scala:
69)
       at scala.actors.ActorProxy.resumeReceiver(ActorProxy.scala:20)
       at scala.actors.Actor$class.searchMailbox(Actor.scala:478)
       at scala.actors.ActorProxy.searchMailbox(ActorProxy.scala:20)
       at scala.actors.Reactor$$anonfun$startSearch$1$$anonfun$apply$mcV$sp
$1.apply(Reactor.scala:114)
       at scala.actors.Reactor$$anonfun$startSearch$1$$anonfun$apply$mcV$sp
$1.apply(Reactor.scala:114)
       at scala.actors.ReactorTask.run(ReactorTask.scala:36)
       at scala.concurrent.forkjoin.ForkJoinPool
$AdaptedRunnable.exec(ForkJoinPool.java:611)
       at
scala.concurrent.forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:
422)
       at
scala.concurrent.forkjoin.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:
340)
       at
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:
325)
scala.actors.SuspendActorControl

scala> future(f) map (42*) respond println
42000000
scala.actors.ActorProxy@34feb215: caught
java.lang.InterruptedException
java.lang.InterruptedException
       at scala.actors.ActorProxy.exit(ActorProxy.scala:32)
       at scala.actors.Reactor$$anonfun$2.apply(Reactor.scala:267)
       at scala.actors.Reactor$$anonfun$2.apply(Reactor.scala:267)
       at scala.Function0$class.apply$mcV$sp(Function0.scala:39)
       at scala.runtime.AbstractFunction0.apply$mcV
$sp(AbstractFunction0.scala:17)
       at scala.actors.ReactorTask.run(ReactorTask.scala:44)
       at scala.actors.Reactor$class.resumeReceiver(Reactor.scala:129)
       at scala.actors.ActorProxy.scala$actors$ReplyReactor$$super
$resumeReceiver(ActorProxy.scala:20)
       at scala.actors.ReplyReactor$class.resumeReceiver(ReplyReactor.scala:
69)
       at scala.actors.ActorProxy.resumeReceiver(ActorProxy.scala:20)
       at scala.actors.Actor$class.searchMailbox(Actor.scala:478)
       at scala.actors.ActorProxy.searchMailbox(ActorProxy.scala:20)
       at scala.actors.Reactor$$anonfun$startSearch$1$$anonfun$apply$mcV$sp
$1.apply(Reactor.scala:114)
       at scala.actors.Reactor$$anonfun$startSearch$1$$anonfun$apply$mcV$sp
$1.apply(Reactor.scala:114)
       at scala.actors.ReactorTask.run(ReactorTask.scala:36)
       at scala.concurrent.forkjoin.ForkJoinPool
$AdaptedRunnable.exec(ForkJoinPool.java:611)
       at
scala.concurrent.forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:
422)
       at
scala.concurrent.forkjoin.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:
340)
       at
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:
325)
scala.actors.SuspendActorControl

Also, it gets even worse when I try the following as program:

import actors.Futures.future

object Main {
 def main(args: Array[String]) {
   val f = (1 to 10000) map (_.toString) length

   future(f) foreach println
 }
}

The output of that is only:
Exception in thread "main" scala.actors.SuspendActorControl

No stacktrace, no effect of println, nothing.

I didn't find anything in the Scala trac, so I assume I am doing
something terribly wrong.

Can anybody help?

Kind regards
Andreas

Thanks for the pointers. I was already aware of the other options but I'm a bit worried about mixing several concurrency libraries, each with their own dispatcher(s) and pool(s). For example, I want to use the parallel collections but also want to use - say - composeable Futures and then maybe also STM and transactors. So I'd have three thread pools, one from the standard lib, one from scalaz and one from Akka, which would mean the number of total threads used would be three times as much as it should be.

Maybe my worries are unfounded but for the time being, I'd prefer to stick with the standard library and would wish it just worked. Oh well.

Josh Suereth wrote:

> Looks like a bug. Somehow you are catching the Actor killing itself when complete (by using Actor.exit). I believe it sends itself the exception to shut itself down, but I don't recall the details.
>
> If you just want to use Futures (and not actors), why not try java.util.concurrent? If you need respond and friends, why not try scalaz.concurrent.Promise, which is fully monadic and awesome.
>
> - Josh

On Mon, Apr 25, 2011 at 6:04 AM, Andreas Flierl wrote:
> Thanks for the pointers. I was already aware of the other options but I'm a bit worried about mixing several concurrency libraries, each with their own dispatcher(s) and pool(s). For example, I want to use the parallel collections but also want to use - say - composeable Futures and then maybe also STM and transactors. So I'd have three thread pools, one from the standard lib, one from scalaz and one from Akka, which would mean the number of total threads used would be three times as much as it should be.

Futures in Akka are composable now in version 1.1 (final not yet
released, but we do have a prerelease out). We also have a akka-scalaz
module that makes Akka's Future work just like Scalaz Promise. And as
far as parallel collections go, it's not much more difficult to work
with a Traversable[Future[T]] then a parallel Traversable[T]. A simple
comparison: https://gist.github.com/912788