recvfrom in its own thread?

I'm developing a multithreaded application that should listen to a specific port over UDP. For listening, I'm considering these two possibilities:

1. I place recvfrom in its own thread. This thread remains blocked on recvfrom until a packet arrives. The rest of the threads continue working.
2. I don't place recvfrom in its own thread. I use select in order to detect incoming packets.

Which choice do you prefer? Which option would consume less CPU while waiting for incoming packets?

Thanks.

Blocking recvfrom is more or less equal to select. When there's no data, the process sleeps. It's woken up when data arives.

The thing with multi-threaded version is that you need to make sure they're not waiting for the data (from recvfrom thread) actively (waiting in for or while) -- that takes processor time.

In general, separate recvfrom thread is not a very effective solution, because you need to pass the data to the other threads. On the other hand, if there's much processing done in each of the other threads, it's worth considering. All depends on the program you're writing.

Originally Posted by estratos I'm developing a multithreaded application that should listen to a specific port over UDP. For listening, I'm considering these two possibilities: 1. I place recvfrom in its own thread. This thread remains blocked on recvfrom until a packet arrives. The rest of the threads continue working. 2. I don't place recvfrom in its own thread. I use select in order to detect incoming packets. Which choice do you prefer? Which option would consume less CPU while waiting for incoming packets? Thanks.

Blocking recvfrom is more or less equal to select. When there's no data, the process sleeps. It's woken up when data arives.

This is not true.

As Mara suggested there is a danger with blocking sockets and thats processor time, but theres a major difference between using select and blocking on recvfrom. Having a thread block waiting for a package will probably max out the cpu and using O_NONBLOCK and constantly polling is not a good idea; while using select on a socket is much more cpu friendly and also allows you to give a time out which can be beneficial.

The main thread should never wait the "recvfrom thread" for a response. This last thread modifies some global variables once a packet is received, while the main thread is working on other tasks. Anyway, we are talking about CPU time and you say that the thread configuration sucks a little more CPU than a loop over select.

If I use select, I could reconsider my program topology. My program comunicates over two rs232 ports and UDP. Using select I could inspect these three file descriptors at the same time. On the other hand, with threads my program remains cleaner and more modular. Every thread does its own job.

Any other opinion or do I take dmail's and Mara's as definitive?

Thanks a lot guys.

The number of threads is critial here. With 100, performance drops and it's clear to see (BTW when writing about threads I meant thread+select inside or thread+blocking operations). In your case, choose what's easier to implement. Threaded solution would not have a big performance drop, but think how to wake them when the packets arrived (a loop waiting for a variable to change is not a good idea).

Mara, I don't like either the idea of looping while waitng a variable to change. But, is not that the same as looping around a select()?

No. The thing is that select (with rather high timeout set) is handled by the system. The process is asleep and it doesn't run until something interesting happens.

OK. I understand that with a high timeout select is a better solution.

I've read somewhere that most linux systems can't manage timeouts smaller than 100 ms. Is this true?

It manages. The question is *when* the call will return. It may be later then the timeout says. It all depends on the kernel, through. In most (?) cases time interrupt comes 100 times per second. Also, your process may not be the one woken up. Timeout passed to select is more or less the time that will pass until the call returns (if there's no other event), I wouldn't count on it if you'd like to have precise measurement.

Thank you very much.