Actors : Future only thread-based?

there's more problems coming. e.g. FutureActor is private, Future:fvalue is private[actors] etc. doesn't look very extensible from the outside, requiring re-writing of quite a bit of code :-(

Am 20.05.2010 um 17:51 schrieb Sciss:

> hi,
>
> is there a reason that Futures : awaitAll / awaitEither requires a thread-based actor (called Actor.receive)? i suppose i shouldn't use it from an event-based actor (that uses loop and react), but will need to bake my own... correct? how would i do that?
>
> like (a bit pseudo-code):
>
> class MyActor extends Actor {
> def act = loop { react {
> case Prepare => {
> val allocMsg = myBuf.allocMsg
> val fut = server !! (1000L, allocMsg, { case allocMsg.success => true; case allocMsg.fail => false; case TIMEOUT => false })
> ... // work here
> await( fut, b => {
> if( b == true ) ...
> else ...
> })
> }}
> ...
> }
>
> so how would my await method look like?
>
> thanks, -sciss-
>

Awaiting the result of a Future is an inherently blocking operation (what should happen if the result isn't immediately available?). Doing so in a non-blocking actor, will, well... block.

- Colin

well, you could have a method which takes the rest of the continuation like react does... like

Futures.awaitAll( timeout, myFuture ) { res => {
...
}}

i am trying now to build exactly that....

Am 20.05.2010 um 21:03 schrieb Colin Bullock:

> Awaiting the result of a Future is an inherently blocking operation (what should happen if the result isn't immediately available?). Doing so in a non-blocking actor, will, well... block.
>
> - Colin

On Thu, May 20, 2010 at 3:11 PM, Sciss <contact@sciss.de> wrote:

well, you could have a method which takes the rest of the continuation like react does... like

Yeah, I almost added a "*except for something involving continuations" disclaimer to my last message. :)

Another (perhaps simpler) option would be to do something like spawn a new actor who's sole job is to await the result, sending the it back in a message to the original actor when (if) it does complete.

- Colin

Ditch futures, embrace promises.

http://gist.github.com/408093

-jason

On Thu, May 20, 2010 at 10:11 PM, Sciss wrote:
> well, you could have a method which takes the rest of the continuation like react does... like
>
> Futures.awaitAll( timeout, myFuture ) { res => {
>        ...
> }}
>
> i am trying now to build exactly that....

There was a series of slides on scalaz actors got posted a while back:http://docs.google.com/present/view?id=ddmk3f43_63zpg3jcgz
All good stuff :)
Just a shame that this is the closest thing I've ever seen to any sort of documentation for the library...


On 20 May 2010 21:59, Jason Zaugg <jzaugg@gmail.com> wrote:

Ditch futures, embrace promises.

 http://gist.github.com/408093

-jason

On Thu, May 20, 2010 at 10:11 PM, Sciss <contact@sciss.de> wrote:
> well, you could have a method which takes the rest of the continuation like react does... like
>
> Futures.awaitAll( timeout, myFuture ) { res => {
>        ...
> }}
>
> i am trying now to build exactly that....

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

hi jason and kevin,

thanks for hinting at the scalaz actors. seems there are quite a few options now.

i just got my own implementation of actors.Future working, so will see if i can get to the end with that one.

looking at the act method of FutureActor:

def act() {
val res = new SyncVar[T]

{
fun(res)
} andThen {

synchronized {
val v = res.get
fvalue = Some(v)
if (enableChannel)
channel ! v
}

loop {
react {
case Eval => reply()
}
}
}
}

i really just hope that DaemonActors get really gc'ed .....

best, -sciss-

Am 20.05.2010 um 22:27 schrieb Kevin Wright:

> There was a series of slides on scalaz actors got posted a while back:
> http://docs.google.com/present/view?id=ddmk3f43_63zpg3jcgz
>
> All good stuff :)
>
> Just a shame that this is the closest thing I've ever seen to any sort of documentation for the library...
>
>
>
> On 20 May 2010 21:59, Jason Zaugg wrote:
> Ditch futures, embrace promises.
>
> http://gist.github.com/408093
>
> -jason
>
> On Thu, May 20, 2010 at 10:11 PM, Sciss wrote:
> > well, you could have a method which takes the rest of the continuation like react does... like
> >
> > Futures.awaitAll( timeout, myFuture ) { res => {
> > ...
> > }}
> >
> > i am trying now to build exactly that....
>
>
>

they do...

Am 20.05.2010 um 22:31 schrieb Sciss:

> i really just hope that DaemonActors get really gc'ed .....

hi (philipp),

the method is

private def await[ A ]( timeOut: Long, fut: Future[ A ])( handler: PartialFunction[ Option[ A ], Unit ]) {
fut.inputChannel.reactWithin( timeOut ) {
case TIMEOUT => handler( None )
case a => handler( Some( a.asInstanceOf[ A ]))
}
}

quite straight forward. only nasty thing is i needed to create my own FutureActor, but well.... seems to be working

best, -sciss-

Am 20.05.2010 um 18:19 schrieb Sciss:

> there's more problems coming. e.g. FutureActor is private, Future:fvalue is private[actors] etc. doesn't look very extensible from the outside, requiring re-writing of quite a bit of code :-(
>
> Am 20.05.2010 um 17:51 schrieb Sciss:
>
>> hi,
>>
>> is there a reason that Futures : awaitAll / awaitEither requires a thread-based actor (called Actor.receive)? i suppose i shouldn't use it from an event-based actor (that uses loop and react), but will need to bake my own... correct? how would i do that?
>>
>> like (a bit pseudo-code):
>>
>> class MyActor extends Actor {
>> def act = loop { react {
>> case Prepare => {
>> val allocMsg = myBuf.allocMsg
>> val fut = server !! (1000L, allocMsg, { case allocMsg.success => true; case allocMsg.fail => false; case TIMEOUT => false })
>> ... // work here
>> await( fut, b => {
>> if( b == true ) ...
>> else ...
>> })
>> }}
>> ...
>> }
>>
>> so how would my await method look like?
>>
>> thanks, -sciss-
>>
>

Hi,

You can await a future in an event-based way using the future's input
channel and `react`:

val ft = future { ... }
// ...
ft.inputChannel.react {
case result => ...
}

Or, if you want to react not only to a resolving future, but also some
other messages:

val Ft = future { ... } // upper-case so can use in pattern
// ...
react {
case Ft ! result => ...
case OtherMessage(...) => ...
}

Also, note that there is no difference between an actor that starts out
as event-based (using `react`, `loop` etc.) and later uses `receive` or
other blocking operations, and an actor that only uses blocking
operations. As long as those blocking operations are based on `receive`
(such as awaiting a future) the underlying ForkJoinPool efficiently
resizes itself (shrinking back when thread-blocking is no longer necessary).

Cheers,
Philipp

Sciss wrote:
> hi,
>
> is there a reason that Futures : awaitAll / awaitEither requires a thread-based actor (called Actor.receive)? i suppose i shouldn't use it from an event-based actor (that uses loop and react), but will need to bake my own... correct? how would i do that?
>
> like (a bit pseudo-code):
>
> class MyActor extends Actor {
> def act = loop { react {
> case Prepare => {
> val allocMsg = myBuf.allocMsg
> val fut = server !! (1000L, allocMsg, { case allocMsg.success => true; case allocMsg.fail => false; case TIMEOUT => false })
> ... // work here
> await( fut, b => {
> if( b == true ) ...
> else ...
> })
> }}
> ...
> }
>
> so how would my await method look like?
>
> thanks, -sciss-
>

how stable and isolated are scalaz actors/promises? i have come to a dead-end with scala-actors due to non-composability of futures - maintainability of my project almost disappeared completely, logic is spread all across the place, no encapsulation whatsoever :-(

the promises-system looks good, but i'm a bit afraid to jump to a beta-state monster project. looking at the source tree, scalaz seems like a monomanic project, and there is basically no documentation, no papers etc.

does akka provide composable futures? again, here i dislike that it is a huge project, and i really just want a performative, documented, clean and encapsulated lightweight actor system....

thanks for more suggestions,

-sciss-

Am 20.05.2010 um 22:27 schrieb Kevin Wright:

> There was a series of slides on scalaz actors got posted a while back:
> http://docs.google.com/present/view?id=ddmk3f43_63zpg3jcgz
>
> All good stuff :)
>
> Just a shame that this is the closest thing I've ever seen to any sort of documentation for the library...
>
>
>
> On 20 May 2010 21:59, Jason Zaugg wrote:
> Ditch futures, embrace promises.
>
> http://gist.github.com/408093
>
> -jason
>
> On Thu, May 20, 2010 at 10:11 PM, Sciss wrote:
> > well, you could have a method which takes the rest of the continuation like react does... like
> >
> > Futures.awaitAll( timeout, myFuture ) { res => {
> > ...
> > }}
> >
> > i am trying now to build exactly that....
>
>
>