Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 14 19:13
    hwanders commented #4096
  • Dec 14 13:05
    IgorFedchenko commented #4085
  • Dec 14 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
Arjen Smits
@Danthar
to be honest. More and more im thinking that reentrancy mode should go away.
Roger Johansson
@rogeralsing
agree
its just too confusing
Natan Vivo
@nvivo
the thing with reentrancy is that it's already supported with self.tell/pipeto
it doesn't need anything else
Arjen Smits
@Danthar
I mean, I cannot think of any scenario where you should not / could not simply refactor the work into an actor
and communicatie using messages
Natan Vivo
@nvivo
exactly
Arjen Smits
@Danthar
in my mind, if you want to use reentrancy, then you dont understand the actor framework
Natan Vivo
@nvivo
@Danthar it's not exactly that
Arjen Smits
@Danthar
and you need to re-evaluate what your are trying to achieve
why not?
Natan Vivo
@nvivo
I think we just need to agree on what the terms mean
in my view
Reentrancy means "processing other things while a logical process didn't finish"
that means, if a message uses "PipeTo(Self)" for example, the logical process didn't finish
you are using reentrancy
Bartosz Sypytkowski
@Horusiath
depends on the definition of logical process
Natan Vivo
@nvivo
a single message was broken into multiple steps, but still a single message from 'outside' was received, and the processing is still just one (even if the actor breaks that into 10)
right. in my sentense, if I say "actor, save these records to the database" - that is a logical process
the amount of messages generated by the actor inside of it to do that thing doesn't matter
the words may be wrong, but my line of thought is correct =)
so, what I mean is that reentrancy using async is unecessary if you look from this perspective. Just PipeTo(Self) and you get the exact same behavior
Bartosz Sypytkowski
@Horusiath
this kind of logical process is easy to define in RPC systems, but Akka isn't necessarily such
Natan Vivo
@nvivo
This is a very abstract description. I think it fits akka just fine
as I said, the behavior is correct. maybe my words are wrong
maybe it's not a logical process.. but it's a single "business request" let's say
Bartosz Sypytkowski
@Horusiath
i.e. "actor, save these records to the database" has no notion of reply behavior, so no PipeTo or even Sender.Tell is necessary ;)
Natan Vivo
@nvivo
ok, now we are probably discussing different things
=)
Roger Johansson
@rogeralsing
we are lacking a description of semantics, that is one reason there is a lot of confusion among ourselves
Natan Vivo
@nvivo
yes. as you said Roger, maybe in a call we can work these things out easily
but as @Danthar said, the current mechanism to support reentrancy with async/await in my opinion is unnecessary. all the stuff that works with syncrhonous code works with asyncrhonous code too.
Arjen Smits
@Danthar
One think I do know.. I need more coffee for this discussion :P
Natan Vivo
@nvivo
@Danthar - just to be clear - I'm agreeing with your point
Arjen Smits
@Danthar
I realised that
Natan Vivo
@nvivo
It's just the way I talk. I'm an architect, my view is very abstract sometimes
Arjen Smits
@Danthar
Noticed that as well.
Roger Johansson
@rogeralsing
I also think the reentrancy was a mistake in retrospect, Orleans have it, but it is just too confusion in the form of async await, new users dont get what it does..
Arjen Smits
@Danthar
it also goes against the actor model imho @Aaronontheweb made a few comments on it last night as well I think
Natan Vivo
@nvivo
I know I'll get burned by this.. but I don't agree with everything @Aaronontheweb said there
Arjen Smits
@Danthar
cant remember what it exactly was he said, but it suddenly made a few things clear for me
Natan Vivo
@nvivo
(async/await) they really make it a lot harder to write clean actor code that complies with the basic concurrency restriction imposed by Akka actors
I don't think that's necessarily the case
Roger Johansson
@rogeralsing
I dont agree with that statement, becuase, it works exactly the same as PipeTo,,, so it is a DSL ontop of PipeTo... however still confusing
Natan Vivo
@nvivo
what happens is that there should be separation between "asyncrhonous akka" and "asyncrhonous method execution"
akka supports asyncrhnous execution by processing individual messages... async/await is another form of asyncrhnous that only refers to how a specific method runs
it's a layer akka shouldn't care
akka should care about messages it receives only. that level of abstraction would make it much easier to reason about
"I'm an actor - I received a message and I won't do anything until I'm done processing it - if that means running async code, so be it.. that doesn't bother me. just let me know when it's done, so I can get the next message"