Handling server requests on different 'threads'

[falconair]

I'm trying to write a simple tcp server. Is there a way to give each client their own thread?

I doesn't actually have to be OS threads. Go's go routines or dart's isolates will work just as well. As long as multiple cores and cpus are being utilized.

I see that I can use web workers. However, every example I have seen shows that I need to pass the name of a source file to the constructor, which this worker then executes. I want to pass in a socket or some other js/ts object, not a source file.

Am I missing something?

[nettybun]

This kind of sounds like an XY problem. Are you sure you need to be using a thread per client? That sounds like a lot of work to manage and you'll need to maintain work queues, delegation, scheduling etc. Deno, like Node.js and all other JS, uses an event loop that allows you to skip the work of multithreading management and let libuv (or whatever the event loop implementation is) handle it for you. Node will use multiple cores for a basic HTTP server, but that is abstracted away from you. See here: https://stackoverflow.com/questions/49141259/does-a-nodejs-server-use-multithreading

[falconair]

Right, I believe I understand event loop/async code. However, all of my, user level, code is still running in the same thread.

Say I accept 20 clients on my server. They send me a message to process, I’m not blocked on any one client. I will, indeed get to process all of those messages. However, those messages will be processed in a single thread, therefore a single cpu core.

However, if I can accept clients and set the client handler to a go routine, an erlang actor, a Java executor or even an os thread, the rest of my CPU’s and cores are likely I be used as well.

I understand I get concurrency with deno, I’m wondering if if there is a library to get parallelism as well.

[nettybun]

20 clients

I promise that even though JS is single threaded you'll be able to serve several thousand requests per second [1] so if you can avoid over-engineering then "true" parallelism might not be worth your time. The answer here is worth a read https://stackoverflow.com/a/17959746

If you still need parallelism then you can do IPC between multiple Deno processes via unix sockets and Deno.connect() but I don't recommend it...

[falconair]

I’ll admit I was thinking ahead and trying to future proof my application, which I haven’t even started writing yet :) I’m trying to understand the ecosystem of deno, go and a couple of other languages.

In my case, I don’t need to serve thousands of clients, but do need to serve a few hundred who may be sending me thousands of messages per second.

In any case, I should just write some code and worry about scaling across CPUs later.

[hoangph271]

One solution for "scaling across CPUs" is deploying multiple instances of your app (we call this a cluster) and there go your multiple processing...!

[nettybun]

Dangerous rabbit hole to go down, but I can totally relate. Mark it as a TODO and move on! Trying to prematurely implementing anything near multi-{threading,processing} will hurt your project's maintainability/readability/etc. Good luck!