by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:50
    storware-mchojnacki opened #4514
  • Jul 13 20:11
    Arkatufus commented #4511
  • Jul 13 20:10
    Arkatufus synchronize #4511
  • Jul 13 18:45
    Aaronontheweb milestoned #4505
  • Jul 13 18:45
    Aaronontheweb labeled #4505
  • Jul 13 18:45
    Aaronontheweb labeled #4505
  • Jul 13 18:45
    Aaronontheweb commented #4505
  • Jul 13 18:26
    Aaronontheweb synchronize #4510
  • Jul 13 18:24
    Aaronontheweb synchronize #4513
  • Jul 13 18:24

    Aaronontheweb on dev

    Use Props.Create<TActor>() inst… (compare)

  • Jul 13 18:24
    Aaronontheweb closed #4509
  • Jul 13 18:24
    Aaronontheweb milestoned #4509
  • Jul 13 18:24
    Aaronontheweb labeled #4509
  • Jul 13 18:24
    Aaronontheweb labeled #4509
  • Jul 13 18:23

    Aaronontheweb on dev

    Use SetItem instead of Add for … (compare)

  • Jul 13 18:23
    Aaronontheweb closed #4512
  • Jul 13 18:23
    Aaronontheweb commented #4512
  • Jul 13 18:22
    Aaronontheweb milestoned #4512
  • Jul 13 18:22
    Aaronontheweb labeled #4512
  • Jul 13 18:22
    Aaronontheweb labeled #4512
Aaron Stannard
@Aaronontheweb
latter being the default
hi @tjaskula
Bart de Boer
@boekabart
I haven't changed any dispatcher configuration
hold on, I did create dispatcher in foreground, in fact, for some system tasks
Aaron Stannard
@Aaronontheweb
I use Topshelf too
ohhhhhhhhh
that would do it
Bart de Boer
@boekabart
isn't that just thread prio?
Aaron Stannard
@Aaronontheweb
nah
the foreground threads are meant to be literally used for user-facing elements
so like the UI thread in an app
Bart de Boer
@boekabart
let me quickly test that theory
Aaron Stannard
@Aaronontheweb
or the thread that owns the console UI
I don't have the details 100% clear off the top of my head anymore
but basically a process can't exit until its foreground threads are joined
Bart de Boer
@boekabart
Yeah, that fixed it.
still a normal console app (not topshelf) didn't suffer from it, it seems. But that one also did less work on that threadpool, so apples and oranges
Aaron Stannard
@Aaronontheweb
akkadotnet/akka.net#2028
just created that
foreground vs. background doesn't change priority
it's the exit behavior that gets affected
Bart de Boer
@boekabart
ok, clear! Re priority btw, again/still suffering from remote disconnects during load; what was that timeout setting again?
I think - there's other settings in there you can adjust also
Bart de Boer
@boekabart
thanks, let's try that..
Aaron Stannard
@Aaronontheweb
one thing we might be able to do, possibly
is add a configuration setting to the ForkJoinDispatcher and the dedicated thread pool
which will allow you to change the priority
I'm comfortable leaving the default where it is
but also fine with users being able to change it
Tomasz Jaskula
@tjaskula
quick question, does the code shared between the actors needs to be synchronized with lock or maybe there some other ways of doing things ?
Aaron Stannard
@Aaronontheweb
@tjaskula you mean shared memory?
every actor instance's memory should be made private
and not shared
if you do need to share data
you should pass that data in an immutable message
that way there's no need for locks and synchronization
and you can still have a high degree of parallelism
Tomasz Jaskula
@tjaskula
I meat rather using for example a common portion of code
like for example you write it once and then you use it for several actors
Aaron Stannard
@Aaronontheweb
oh
just methods / functions?
Tomasz Jaskula
@tjaskula
let say I have something I want to use on PreRestart for every actor
like writing to some DB log or something
Aaron Stannard
@Aaronontheweb
ah
every one of those actors
should be given their own instance of that object
part of the goal of the actor model
is to avoid locking / shared state concurrency
the other thing you can do