Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 14 21:02
    Aaronontheweb synchronize #3975
  • Oct 14 21:02
    Aaronontheweb opened #3975
  • Oct 14 20:11
    IgorFedchenko commented #3973
  • Oct 14 20:10
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 20:06
    IgorFedchenko synchronize #3973
  • Oct 14 19:42
    IgorFedchenko edited #3973
  • Oct 14 18:08
    Aaronontheweb commented #3937
  • Oct 14 17:27
    Aaronontheweb commented #90
  • Oct 14 17:26
    Aaronontheweb commented #90
  • Oct 14 17:25
    Aaronontheweb assigned #90
  • Oct 14 17:16

    Aaronontheweb on dev

    Provide static GetRoutees.Insta… (compare)

  • Oct 14 17:16
    Aaronontheweb closed #3974
  • Oct 14 17:16
    Aaronontheweb milestoned #3974
  • Oct 14 16:05
    jackowild opened #90
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 14 15:08
    Aaronontheweb commented #3974
  • Oct 13 14:40
    cptjazz synchronize #3974
  • Oct 13 14:07
    cptjazz opened #3974
  • Oct 13 08:30
    ismaelhamed commented #3937
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"
Arjen Smits
@Danthar
I agree, But I don't think we have that luxery
Natan Vivo
@nvivo
Yes, after looking at the dispatchers, I think it's not that simple to achieve that. but it's possible
I wonder what the akka guys would say about that
Roger Johansson
@rogeralsing
they didnt build async support because they thought it was confusing.
Had a talk with them early on
Natan Vivo
@nvivo
Do you still think that's confusing?
Natan Vivo
@nvivo
it seems he was talking about reentrant behavior
I think we concluded that it was inherently unsafe because if the continuation is "never" resumed, the actor is effectively dead and its mailbox will continue to pile up. Pausing processing is anti-responsive.
This is an error in the assumption that anything is being paused
Arjen Smits
@Danthar
@rogeralsing Concerning that link; Im all for option 1
Natan Vivo
@nvivo
The behavior is exactly the same as if you were burning cpu cycles doing something. it's just a message being processed
Roger Johansson
@rogeralsing
@Danthar that is what we do in the suspend behavior now
Natan Vivo
@nvivo

he said then

There is a compromise that is possible, though: enqueue incoming messages locally until the continuation has been resumed and completed (so that users are not surprised) until the local queue is full, at which point the actor fails. This places a limit on the non-responsiveness while not breaking semantics.

this seems to be your option 1
that is exactly what async/await should do in fact
Bartosz Sypytkowski
@Horusiath
@nvivo not only, while message is being processed, state changes
(I'm talking about reentrancy right now)
Natan Vivo
@nvivo
yes, that's why reentrancy should be handled by message passing, not a custom mechanism on top of async/await
the reason async/await exists is just to make syncrhnous code non-blocking, it was never intended to create a notion of parallelism
IMO, there is no need to change that because Akka already supports PipeTo very well
Bartosz Sypytkowski
@Horusiath
while about your quote - persistent actors in fact stash incoming messages while in recovery phase, but this is destructive when used in some routing strategies
Natan Vivo
@nvivo
the quote is from Roland Kuhn, just to be clear
Bartosz Sypytkowski
@Horusiath
yep, I've read the thread ;)
Roger Johansson
@rogeralsing
I think our "Feasiblity" bouble is quite small here due to the implicit context. so that limits our options

Roger Just unlocked Pointy Haired Boss acheivement - posting nonsense venn diagrams

:)
Arjen Smits
@Danthar
lol
Maybe some UML diagrams would be better
:P