Multithreading UDP server with epoll?

Question

I\'d like to develop a multithreaded UDP server in C/Linux. The service is running on a single port x, thus there\'s only the possibility to bind a single UDP socket to it. In o

Answer 1

As you are only using a single UDP socket, there is no point using epoll - just use a blocking recvfrom instead.

Now, depending on the protocol you need to handle - if you can process each UDP packet individually - you can actually call recvfrom concurrently from multiple threads (in a thread pool). The OS will take care that exactly one thread will receive the UDP packet. This thread can then do whatever it needs to do in handle_request.

However, if you need to process the UDP packets in a particular order, you'll probably not have that many opportunities to parallalise your program...

Answer 2

No, this will not work the way you want to. To have worker threads process events arriving through an epoll interface, you need a different architecture.

Example design (there are several ways to do this) Uses: SysV/POSIX semaphores.

• Have the master thread spawn n subthreads and a semaphore, then block epolling your sockets (or whatever).

• Have each subthread block on down-ing the semaphore.

• When the master thread unblocks, it stores the events in some global structure and ups the semaphore once per event.

• The subthreads unblock, process the events, block again when the semaphore returns to 0.

You can use a pipe shared among all threads to achieve very similar functionality to that of the semaphore. This would let you block on select() instead of the semaphore, which you can use to wake the threads up on some other event (timeouts, other pipes, etc.)

You can also reverse this control, and have the master thread wake up when its workers demand tasks. I think the above approach is better for your case, though.