Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:13
    valdisz commented #3921
  • Oct 21 15:57
    Aaronontheweb closed #3877
  • Oct 21 15:57
    Aaronontheweb commented #3877
  • Oct 21 15:56

    Aaronontheweb on dev

    Persistence TestKit documentati… (compare)

  • Oct 21 15:56
    Aaronontheweb closed #3889
  • Oct 21 07:27
    dependabot-preview[bot] labeled #3999
  • Oct 21 07:27

    dependabot-preview[bot] on nuget

    Bump FluentAssertions from 4.14… (compare)

  • Oct 21 07:27
    dependabot-preview[bot] opened #3999
  • Oct 20 17:25
    valdisz synchronize #3889
  • Oct 20 17:17
    valdisz synchronize #3889
  • Oct 20 15:44
    valdisz synchronize #3889
  • Oct 20 09:22
    ismaelhamed commented #3863
  • Oct 19 23:39
    valdisz synchronize #3889
  • Oct 19 23:08
    edvinasz commented #2947
  • Oct 19 13:36
    Aaronontheweb commented #3973
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3995
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump BenchmarkDotNet from 0.10.… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] edited #3995
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3993
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Google.Protobuf from 3.9.1… (compare)

Roger Johansson
@rogeralsing
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
Roger Johansson
@rogeralsing
dude you have no idea how much UML I have done in my days :) spent a few years drawing sequence diagrams at my last job...
Arjen Smits
@Danthar
hehe
So should be no problem then!
^^
Roger Johansson
@rogeralsing
read the thread
Natan Vivo
@nvivo
Haha
Natan Vivo
@nvivo
was thinking about all of this ... one problem with "tasks" in c# is that it mixes the idea of a promise with the execution of code asyncrhonously
I heard a typesafe guy saying the same thing about java futures, so there is probably a performance reason there
if the future value was to be separated in an IPromise<T> for example, I guess async/await wouldn't be so mysterious
Stefan Sedich
@stefansedich
@rogeralsing decided to clean up the whole Event namespace.
I assume we have the R# rule for comment all protected/public? it really gets annoying for obvious methods. I have found myself hating myself :)
also there are one or two Obsolete still in Logging, is it safe for me to kill them now?
Natan Vivo
@nvivo
This message was deleted
Stefan Sedich
@stefansedich
I don't like seeing deleted messages :D
too curios
I wish they just removed it totally.
Natan Vivo
@nvivo
haha
it was the secret of the universe, life and everything
Stefan Sedich
@stefansedich
I knew it!
Natan Vivo
@nvivo
@rogeralsing just to get this out of the way, went digging into .net await just to see how it captures the context. as far as I can see, there is no difference between the way LogicalCallContext and SyncrhonizationContext flow between executions, except SyncContext is passed by reference and CallContext is cloned (so there is a little bit overhead there as you noticed), but CallContext always flows while SyncContext is optional. That means you're right in using that, there is no reason to try using a SyncrhonizationContext there.
jcwrequests
@jcwrequests
I thought everyone might like a distraction from the TPL discussion and might find thus post interesting. http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx
Natan Vivo
@nvivo
I found a smell on the actor task scheduler that may account for most problems that are showing, but I'm too tired to investigate today. Boils down to where CallContext is set and restored... I may take a look tomorrow.