There is a popular misconception that GenServer provides a means to structure programs, hide information etc. This is not the case. Elixir and Erlang programs are structured as modules containing functions. If you need to “do calculations in one place”, you use a function, not a server. If you have requirements for shared state then the particulars of those requirements determine the solution.

Building Non Blocking Erlang apps

Also: Why does this simple GenServer timeout?

Your could for example launch the calculation call via Task.async/1 which gives you a %Task{owner: term(), pid: term(), ref: term()}. Store that together with the caller details in the GenServer state.

When the task is done, you’ll get a {ref,result} via handle_info and you can complete the call with GenServer.reply/2.

For a cleaner result, also take care of the details like Task.await does, i.e. demonitor and process :DOWN messages

Can you talk about your use case for the GenServer? GenServers are single threaded, that’s just what they are, there’s no getting around that. There’s probably a way to solve your problem without using a single GenServer, but we can’t recommend one without details about what it does.

The point is that each request should already be running in it’s own process. Therefore each isolated request can make the call independently (and be blocked) and then has to wait for it’s own call to return. So things are already inherently concurrent.

By introducing a single GenServer that all requests have to go through you have created a bottleneck.

So the question becomes, what is the benefit that this bottleneck gives you?

That calculations for each of them have to be made at the same time not one by one.

So have each request do its own calculations …

A single GenServer process can only ever work sequentially. If you need concurrency you need to spawn multiple processes.