Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:41
    Aaronontheweb commented #4097
  • 08:19
    ismaelhamed synchronize #4097
  • 02:22
    kimbyungeun opened #4098
  • Dec 15 19:47

    Aaronontheweb on dev

    TypeExtensions.TypeQualifiedNam… (compare)

  • Dec 15 19:47
    Aaronontheweb closed #4071
  • Dec 15 19:47
    Aaronontheweb closed #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb labeled #3767
  • Dec 15 19:47
    Aaronontheweb milestoned #3767
  • Dec 15 19:44
    Aaronontheweb labeled #4097
  • Dec 15 19:44
    Aaronontheweb milestoned #4097
  • Dec 15 13:23
    Aaronontheweb commented #4096
  • Dec 15 13:22
    Aaronontheweb commented #4093
  • Dec 15 13:16
    ismaelhamed commented #4093
  • Dec 15 13:04
    ismaelhamed edited #4097
  • Dec 15 13:04
    ismaelhamed opened #4097
  • Dec 15 12:50
    ismaelhamed commented #4096
  • Dec 15 12:48
    ismaelhamed commented #4096
  • Dec 15 12:05
    Aaronontheweb commented #4096
  • Dec 15 11:43
    ismaelhamed commented #4096
Stephen Riley
@stephen-riley
The more I think about it, @me-slove, I just wasn't thinking hard enough about how TPL works vis-a-vis the different threads your Task<T> might continue on, and how Akka won't know anything about that. Completely different runtime contexts.
I'm gonna have to think a lot more about this and how I would want this to work ideally so I had something like ContinueWith() that was Akka-aware. Anyway, thanks for the thoughts.
Aaron Stannard
@Aaronontheweb
@stephen-riley we resolve Context by checking a thread-local variable
the value of Context is therefore, volatile
on top of that, the Context can change each time an actor processes a message
so it's a good practice to close over things like Sender and Self when you want to use them in continuations
Stephen Riley
@stephen-riley
heh, glad you confirmed that for me, @Aaronontheweb , as looking into the thread-local storage aspect of it was next on my list. :smiley: This is quite fun digging into this all!
Aaron Stannard
@Aaronontheweb
no problem
normally none of that stuff is an issue when you're working inside an actor
but yeah, when you want to re-use some of that state asynchronously
Stephen Riley
@stephen-riley
This really all started from "why do I need to explicitly specify a sender in Tell() while inside a continuation?" Been quite a lot of fun digging in.
Aaron Stannard
@Aaronontheweb
ah yeah
because our extension method that automatically supplies Self doesn't work outside the ActorCell
Context is basically the public API of the ActorCell
Stephen Riley
@stephen-riley
I know I could/should use PipeTo() for what I'm doing to be a little more "proper" about things, but you know how it is: once you start pulling a thread, you gotta see what unravels. :smile:
Aaron Stannard
@Aaronontheweb
I know how that feels
Stephen Riley
@stephen-riley
Ah, okay. I need to read up on ActorCell, clearly.
Aaron Stannard
@Aaronontheweb
ActorCell is what fits all of the different pieces of an actor together for user-defined actors
and most, but not all, built-in actors
connects the mailbox to the dispatcher to the actor implementation class
it's also what allows for safe restarting of actors too
there are some built-in actor types that operate without a cell, but they're special cases
router actors are one example
typically they're actors that don't need to obey the 1 message at a time guarantee
Stephen Riley
@stephen-riley
Ah, okay. So it's really the central "actor infrastructure state" thing per thread, and encapsulates the context on which my actor code is running?
Aaron Stannard
@Aaronontheweb
yep
the dispatching infrastructure in Akka.NET basically queues up groups of actors for processing
and can dispatch actors to work across an arbitrary number of threads
but one actor can only work on one thread at a time
if the actor still has unprocessed messages in its mailbox once it's finished
Stephen Riley
@stephen-riley
So, hypothetically, if I wanted to create a library of continuation extension methods (eg. something like ContinueActorWith()), it's all about managing the ActorCell for the continuation code to run on?
Aaron Stannard
@Aaronontheweb
it gets rescheduled back onto the dispatcher again for more processing
if you stick with what gets exposed via ActorContext
or whatever the Context interface is
that's all of the stable parts of the Cell API
and exposes everything you care about
most of what the ActorCell does internally is stuff like managing child actors
and handling deathwatch
etc
Stephen Riley
@stephen-riley
Ah, okay.
Aaron Stannard
@Aaronontheweb
there's some internal plumbing that might be interesting
albeit, it's unsafe
but it's public API
Stephen Riley
@stephen-riley
roger that.
this is the ThreadStatic variable I mentioned earlier
we have a more safe way of exposing that somewhere
I don't remember where it is off the type of my head
but if you're curious about the internals, the ActorCell stuff is really at the heart of the actors
Stephen Riley
@stephen-riley
No worries. I'll dig around.