Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Dec 12 15:42
    Aaronontheweb opened #4093
  • Dec 12 14:20
    Aaronontheweb commented #4092
  • Dec 12 14:14
    Aaronontheweb labeled #4089
  • Dec 12 14:14
    Aaronontheweb labeled #4089
  • Dec 12 14:11
    Aaronontheweb synchronize #4089
  • Dec 12 14:10
    Aaronontheweb synchronize #4086
  • Dec 12 14:09

    Aaronontheweb on dev

    Convert to ImmutableHashSet for… (compare)

  • Dec 12 14:09
    Aaronontheweb closed #4090
  • Dec 12 12:04
    nagytech synchronize #4092
  • Dec 12 11:53
    nagytech synchronize #4092
  • Dec 12 11:49
    nagytech edited #4092
  • Dec 12 11:40
    nagytech opened #4092
  • Dec 12 11:32
    nagytech edited #4091
Roger Johansson
@rogeralsing
@nvivo we used the thread static container from the start as there were no plans for async await, nor did we know about call context. then we discivered callcontext along the way. in theory we should be able to use call context all the way.. but xUnit blows up when using call context. the test runner explodes when the test finishes
@nvivo but you are correct that this is the ideal way to solve it, if everything else behaves as it should
@nvivo and then the TestKit should work. but at least in xUnit 1.9.2, we are out of luck
Arjen Smits
@Danthar
CallContext has some stuff you need to be aware off.
Started digging and found a blog which explains it pretty well. Commented on the issue. I wont go into detail here, Because I would like to keep this discussion over at github as much as possible.
Natan Vivo
@nvivo
@Danthar just read the blog post about CallContext, thanks
Just out of curiosity, I went to see how Orleans did it, it appears they don't have synchronizationcontext. but then, I think they don't have any implicit state the same way akka does
Roger Johansson
@rogeralsing
ye, the implicit context is the root of all async evil in akka.net
Natan Vivo
@nvivo
so... thinking about the future here and akka typed and these issues
what if...
what if we checked if synccontext solves the problem first
and had a way to disable it
Roger Johansson
@rogeralsing
but how can we use synccontext when we dont own the threads?
Arjen Smits
@Danthar
@rogeralsing I agree. The fact that we need to carry state around is the cause of most of our TPL issues
Natan Vivo
@nvivo
just thinking out loud here
winforms/wpf/asp.net require synccontext but only for some special cases where you want to run in that ui thread
those are minor cases. maybe if synccontext worked, akka.net could still run in those environments without context
Arjen Smits
@Danthar
Akka is the same @Nvivo
Roger Johansson
@rogeralsing
we have our dispatchers, they could dispatch onto whatever, thread pool, new threads, existing threads, someone elses threads.
Natan Vivo
@nvivo
@Danthar sorry, didn't get it
what is the same?
Roger Johansson
@rogeralsing
so we cannot assume we have the right to change the synccontext on an existing thread
Natan Vivo
@nvivo
i know
Arjen Smits
@Danthar
look at it like this: Akka has its own gui context. Only then its not the GUI but the actor context it needs to marshall back on
Natan Vivo
@nvivo
I get what you're saying, I don't know why =)
what did I say?
Arjen Smits
@Danthar
winforms/wpf/asp.net require synccontext but only for some special cases where you want to run in that ui thread
Natan Vivo
@nvivo
maybe I expressed myself wrong
Arjen Smits
@Danthar
and the bit about maybe running in environments without context
Natan Vivo
@nvivo
let me try again
Arjen Smits
@Danthar
akka will always have its own local actor context it needs to carry around
Natan Vivo
@nvivo
the reason akka cannot assume it can change sync context is because of these environments? or are there more reasons?
Roger Johansson
@rogeralsing
Steven Cleary who wrote that blogpost wrote somewhere else that if you do own the thread: synccontext, if you dont own the thread, TaskScheduler
Natan Vivo
@nvivo
because at least from my perspective, even in asp.net or winforms, I'd usually run the actor system in the default thread pool for almost everything
this is the part where I get confused
Arjen Smits
@Danthar
:nods: But what will happen when you switch to another dispatcher implementation. like one that does not use the threadpool ? How will the TPL react to that? I really have no idea
Natan Vivo
@nvivo
too many subjects. that's the part where talking is easier to follow up =)
Roger Johansson
@rogeralsing
Orleans have its own mini threadpool afaik, so they can do whatever they want
Natan Vivo
@nvivo
right
and dedicatedthreadpool is nowhere near what threadpool is currently
Still, what I get confused is that stephen cleary also has some examples of creating your own sync context and I don't remember reading about requiring your own thread pool
i need to read more about this
I think this idea of "owning the thread" is not exactly creating the thread yourself
but i may be wrong
Roger Johansson
@rogeralsing
Ill see if I can find the post
Natan Vivo
@nvivo
I'm thinking about posting a question on stackoverflow and see if he answers
I think you sent me the post link once in a discussion
what I'd like to know is: if syncrhonizationcontext seems to be the only safe way to keep context between async calls, is it possible for us to implement one safely using the thread pool?
and note that at this point I'm not worried about how to run akka in ui threads, I'd just like to know if that is possible or not
Arjen Smits
@Danthar
Its should be possible