在 2014年4月29日星期二UTC+8上午4时50分46秒，rkuhn写道：
>
> Yang Bo,
>
> thanks for experimenting with and sharing this: when macros started to
> materialize two years ago I had the same thought and proposed (internally)
> to investigate what I called messageflow at the time (inspired by our
> dataflow module which has been treated in the same fashion, going from CPS
> plugin to async/await macros). This model makes for a nice and direct way
> of formulating temporary intermediate states within actors, typically
> encountered while waiting for another actor to reply. Interestingly, the
> original work on the Actor model (in particular by Gul Agha) already
> contains this as a primitive of the actor language.
>
> On the other hand I have learned a few more things over the past year that
> are related to this topic as well. Perhaps the most concise write-up is
> this issue<https://github.com/reactive-streams/reactive-streams/issues/46> on
> the Reactive Streams repository. What you are doing is that the actor is
> not technically blocked (in the sense of parking a thread), but it is still
> logically blocked, since it cannot handle any message other than the reply
> that is being awaited—everything else would violate the Actor model in that
> concurrent entry into the behavior is not allowed: handling a message must
> determine the behavior that applies to the next message, and this process
> is applied strictly in sequence. We discussed this topic also with Akara
> Sucharitakul and Justin du Coeur on this list a few months ago (search for
> the Aggregator Pattern), and what we concluded was that mixing a normal
> actor (with the current behavior as the message entry point) with an
> `await` scheme (that adds secondary message entry points) would lead to
> confusing behavior in that e.g. a Cancel message would not have the
> intended effect:
>
> def receive = {
> case DoWork =>
> val r = otherActor ? Query await 5.seconds // this uses become()
> under the hood
> sender() ! Reply(transform(r))
> case Cancel =>
> context.stop(self)
> }
>
> Now what you are showing is a slight variation on this theme in that your
> actor does not actually have the normal `receive` entry point for
> processing. If I read it correctly, then your macro only applies to actors
> that model ephemeral workflows in a single-shot fashion, with full control
> on which message is expected next.
>
Unlike scala.async <http://docs.scala-lang.org/sips/pending/async.html>,
stateless-future-akka imposes only little limitation in Scala language
feature. Of course you may use match in a FutureFactory.Future, and get rid
of the buggy continuation plugin.
> That is a very interesting spin, and it might actually work! I would love
> to see how something like the following would pan out:
>
> class OrderFlow(item: Item, client: Client, inventory: ActorRef, shipping:
> ActorRef, billing: ActorRef) extends Workflow {
> implicit val timeout = Timeout(300.millis)
> flow {
> // .await(duration) returns an Option[T]
> val reserved = inventory ? ReserveItem(item) await 500.millis
> getOrElse ReservationTimeout match {
> case ItemReserved(reserved) => reserved
> case other =>
> context.parent ! OrderFailed(other)
> flow.stop() // e.g. throw ActorKilledException
> }
> val shipped = shipping ? ShipItem(reserved, client) await 500.millis
> getOrElse ShippingTimeout
> val status = if (shipped.wasSuccessful) {
> val billed = billing ? InvoiceItem(reserved, client) await
> 500.millis getOrElse InvoiceTimeout
> if (!billed.wasSuccessful) {
> shipping ! RollbackShipItem(shipped)
> BillingFailed
> } else {
> OrderSuccess
> }
> } else {
> ShippingFailed
> }
> context.parent ! status
> }
> }
>
> This would be a specialized actor with a `final override def receive` that
> can only be used via the flow{} DSL. The core of this proposal is that an
> actor is either unrestricted (with receive/become) or a single workflow,
> but never a mix of the two.
>
> Regards,
>
> Roland
>
> 27 apr 2014 kl. 22:06 skrev 杨博 <[email protected] <javascript:>>:
>
>
>
> 在 2014年4月27日星期日UTC+8上午2时15分31秒，Justin du coeur写道：
>>
>> On Fri, Apr 25, 2014 at 4:00 PM, 杨博 <[email protected]> wrote:
>>
>>> Does this project interest you or scare you?
>>>
>>
>> Somewhere in-between, I'd say -- I'm intrigued but cautious. The concept
>> is *quite* interesting, and for some state machines I can imagine it being
>> enormously useful. That said, while it's obvious how it works for a single
>> entry point, I'm not clear on how it would work with one of my typical
>> Actors, which often respond quite differently to half a dozen different
>> messages. If this is so deeply become-based, it *sounds* like it might
>> have problems when those are interleaved.
>>
> I guess I won't resolve this problem at any time. Yes, I can resolve it by
> dispatching different message to different Futures in one actor. But IMHO,
> it's not the best design model with Akka. I suggest you forward different
> messages to different actors, and use Future in those actors.
>
>
>
>> But the generated code is so voluminous, I can't quickly figure out if
>> that's true. (The bulk of the generated code is a mild concern as well,
>> although not a dramatic one if the size of the generated code is roughly
>> linear with the original.)
>>
>> How well does the Future mechanism play with more heterogeneous Actors,
>> with a bunch of different entry points?
>>
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
> twitter: @rolandkuhn
> <http://twitter.com/#!/rolandkuhn>
>
>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
