Does the Linux or BSD kernel slow down if a program has a bunch of threads in a blocking io state, or is the performance deficit so negligible that it can be ignored. I am writing a server program that will handle ~7000 clients and am wondering how bad the performance hit would be if 1000 of those clients just idled for 2 hours. I am using a basic consumer machine that will run Debian Linux or OpenBSD BSD.
I am using C and C++.
If those threads are waiting for an event most of the time, there are no drawbacks except, of course, some memory eing eaten. E.g., each (kernel) thread has its own stack, which is 4..16 MB usually on modern amd64 systems. Unless you're starting a thread for each of the 7000 clients you have, there will be no problems: kernel won't touch those threads at all while some I/O or signal won't happen there.
If you really plan to have 7000 kernel threads... you'd better not. Please look at non-blocking I/O, in particular, the good starting point will be the portable poll(2) API. This is what much of modern high-performance software like nginx uses under the hood to handle a lot of network clients simultaneously.