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
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
Roger Johansson
@rogeralsing
I cc'ed Stephen in our issue now
but if we use CallContext, and only store single values and not mutating any structure, that should be safe, no?
Natan Vivo
@nvivo
I guess it would, but I still think setting the call context is not the best performance. in theory, sync context should be faster because we don't need to guess when it needs to be set
Arjen Smits
@Danthar
Its at least worth a try. but its really hard to test
Natan Vivo
@nvivo
although in theory, the same solution should be possible with callcontext if we control the schedulers
maybe I'm talking 2 different things
Roger Johansson
@rogeralsing
the good think now, is that everyone involved seem to understand what the problem is :) that was a bit of a pain initially to try to communicate
Natan Vivo
@nvivo
roger, one thing that puzzles me is this
when using the synccontext, it seems the way it works is that context is captured when the task is scheduled, and brought back when the task will run
but akka seems to set the callcontext in other places outside of the scheduler
is this right? I may have to look at the code again
Roger Johansson
@rogeralsing
this is because of reentrancy.. if we only had the "suspend" behavior, that would be easy to solve the way you describe, but as we can multiplex many messages on the same actor, we need to re-set the context
as continuations are piped back as messages
Natan Vivo
@nvivo
found here... it's set in the actortaskscheduler only
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