I posted a question on SO whether two threads can simultaneously execute a send() and a recv() on the same socket. I was told that while they could, implementing this was an example of a very poor design.

My rationale is that packets must be sent every 20ms, so I cannot wait until I receive something before I send anything. I thought designating a thread to perform the sending will make it easiest to keep this 20ms interval untouched by any unrelated processing overhead.

Why is it such a bad idea and what are better designs?

  • It seems one person felt it was poor design, and he seemed to be arguing that you should be using another solution (like the asynchronous solution guest provided in an answer to this question). However, it does sound like you need to carefully think about what it means if "packets must be sent every 20ms." That phrasing suggests you need to understand your timing tolarances to make sure your solution works.
    – Cort Ammon
    May 24, 2017 at 22:51

1 Answer 1


It isn't necessarily bad design, but in an application with lots of connections it will increase your thread consumption (possibly to the point where you can't create more threads).

To support large numbers of sockets with small numbers of threads, you would turn to asynchnous IO, using the select(2) system call.

If you're only expecting a few connections, and want to ensure that your sender isn't blocked by a receiver, then two threads is fine.

BUT, be aware that you have no guarantees that the Linux scheduler will run your sender every 20 milliseconds. It might get close, depending on how many other threads are running (across all processes in the system) and what priority your assign to your thread. But unless you use a real-time operating system, your sender may be delayed for an arbitrary amount of time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.