4

I'm implementing a socket server. All clients (up to 10k) are supposed to stay connected.

Here's my current design:

  1. The main thread creates an event loop (use epoll by default) and a watcher for accepting clients.
  2. The accept callback
    • Accept fd and set it to non-blocking mode.
    • Add watcher for the fd to monitor read events.
  3. The read callback
    • Read data and add a task to thread pool to send response.

Is it OK to move read part to thread pool, or any other better idea? Thanks.

rance.attack
  • 43
  • 1
  • 6

1 Answers1

1

Hard to say. You don't want 10k threads running in the background. You should keep the read part in the main thread. This way if suddently all clients start asking for things, you pile those resources only in the threadpool queue (You don't end up with 10k threads running at the same time). Also you might get better performance this way because you avoid doing some unnecessary context switches (between your own threads).

On the other hand if your clients are unlikely to send requests at the same time, or if the replies are very simple, it might be simpler to just have one thread per client, and avoid the context switch between the main thread and the thread pool.

Sorin
  • 11,863
  • 22
  • 26