any new technology or techniques for private servers development?

[Spirited]

Originally Posted by Xio.

Dude your ****** phoenix mess uses encrypted inter process comunication... now thats ******* useless imo.

[Xio.]

Originally Posted by Korvacs

You don't understand what the threadless async/await methodology is about.

await Task.Run();

This is correct, because you don't have to use a thread waiting for that task to complete because you are using await, to say that you can go beyond that and not have a thread running while executing code isn't possible.

All that changes is that the calling thread is freed up and can be used for other uses in the mean time instead of blocking, the code still has to execute somewhere.

Well it all depends on which Synchronisation context you specify. I use a seperate context to limit those kinds to one threadpool thread instead of scheuduling it to a random free one.

[Korvacs]

Originally Posted by Xio.

Well it all depends on which Synchronisation context you specify. I use a seperate context to limit those kinds to one threadpool thread instead of scheuduling it to a random free one.

You still don't understand, that line I posted runs the Task, it doesn't matter where it runs it, threadpool, other thread, your own threadpool. It still has to run somewhere using a thread/threads. The thread that called it is effectively parked and can be used somewhere else in your application, most likely for more async/await methods.

You can of course change the context, but that wont fundamentally change how this works. I disagree with your decision to use a specific thread on the threadpool, if you want this sort of precision you should create your own thread, not rely on the threadpool (because you're not using it as it was intended).

[Xio.]

Async methods are intended to be non-blocking operations. An await expression in an async method doesn’t block the current thread while the awaited task is running. Instead, the expression signs up the rest of the method as a continuation and returns control to the caller of the async method.
The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread. The method runs on the current synchronization context and uses time on the thread only when the method is active. You can use Task.Run to move CPU-bound work to a background thread, but a background thread doesn't help with a process that's just waiting for results to become available.
The async-based approach to asynchronous programming is preferable to existing approaches in almost every case. In particular, this approach is better than BackgroundWorker for IO-bound operations because the code is simpler and you don't have to guard against race conditions. In combination with Task.Run, async programming is better than BackgroundWorker for CPU-bound operations because async programming separates the coordination details of running your code from the work that Task.Run transfers to the threadpool.



I said

Not using "await Task.Run()"

You can run tasks on one thread. Task.Start(Scheduler) if done properly will use only one thread. You can verify by using a loop and print out the managed thread id. They complete in a different order than being executed which also implies that they run "at the same time", asynchronusly.

I have my own pool of 6 Threads that do everything. The only Threadpool usage would be the BeginXX EndXX Sockets since they use the threadpool internally. I run 6 threads with sync contexts and queues that allow me to shoot tasks on them and utilize each thread efficiently. Each thread has a given "core task": PacketQueue In / Out, Mobs, Players, Map and Item. All those threads get tasks shot at them and they work pretty nicely parallel.

Since every packethandler is a task, a active server should have a high change in active threads if they were spawning / utilizing threadpool threads yes?
I appreciate your feedback Korvacs since you have experience in running servers as opposed to fang.