got it
I opened an idea on .net fiddle for them to fix the buffering of console.log. this is required in every fiddle we do in for akka.net. would help if people voted so they can prioritize: https://dotnetfiddle.uservoice.com/forums/228764--net-fiddle-ideas/suggestions/7623540-flush-the-console-buffer-after-run
but the guy you should talk to about redoing the MultiNodeTestRunner is @smalldave
err
child process debugger
sorry, still on my first cup of coffee
to answer your question though, I don't know what the downsides would be of using an AppDomain - part of me think it's a better idea to leave this stuff as-is and let each node have its own independent process-level resources
but don't all .NET processes share the same threadpool anyway?
i.e. isn't the CLR threadpool a shared resource across all of them? or is that not right?
shared across appdomains
but not processes
damnit now I'm confused http://blogs.msdn.com/b/ericeil/archive/2009/04/23/clr-4-0-threadpool-improvements-part-1.aspx
my brain this morning http://i.imgur.com/NIOYi.gif
finally
Ehm, you just can't share a thread across processes. Whether ThreadPool is shared between AppDomains depends on CLR host. I. e. custom CLR host can even run multiple CLR threads on one native thread ( see https://msdn.microsoft.com/en-us/library/74169f59.aspx )
Haven't seen such CLR hosts, but still
thread is a resource of the process
should have been obvious but I drank a lot of wine last night
I think it's implemented like namespaces (i. e. groups of processes that have different network stacks, process PID space, etc)
and our build runner crashes on one of those runs, after successfully completing the tests a previous time
that's good to know @kekekeks
same place each time - test 48 in Akka.Cluster causes a stackoverflow inside XUnit
dispatchers and mailboxes are totally decoupled in Akka.NET
you should be able to set that for an actor