I see that there is a notional window there, but I think it only exists conceptually, if you only consider a single running thread at a time.

On a single cpu machine, when any given thread is in that window between the accept timing out and the new accept being issued, every other thread, whilst dormant, still has an open accept on the same port (or is awaiting a timeslice to finish processing before re-issuing it's accept).

If you have multiple threads running, the window in which all threads would be either processing data, or in between the timeout and the re-issue of the accept is vanishingly small.

On a multi-cpu machine, even if you only have one more thread than cpus, the possibility of none of your threads having an accept in progress is pretty small.

If you have double the number of threads as cpus, it becomes statistically very improbably.

You have to realise, that even if a given thread has an accept in progress when the connect arrives, the odds are very high that it will not currently be in a timeslice. So most times, there will be a small delay between the connect occuring and the thread that accepts it getting a timeslice to complete the accept. This is true even of a non-threaded socket program running on a multi-tasking OS. So long as there is at least one thread that has an open accept, the tcp/ip stack / driver will accept the connect and 'hold' it until an appropriate thread or process gets a timeslice.

The more threads you have issuing the accept on the appropriate port, the less likely that they will all be out of the accept wait state at the same time. It is not zero, but with even 5 threads, it is really very small.

I'm not overly familiar with the detailed nitty gritty of tcp, but even in a traditional accept'n'fork model, there is a similar window between the accept occuring and it being re-issued. Even with a "dedicated" accept process, that process is still subject to being swapped at the schedulers convenience. It is only notionally "always running".

I would say that that window is larger in the forking model, as even on COW optimised OSs, the process still has to be cloned, and then the new process will get the next timeslice. So the parent will have to wait until the new process finishes it's timeslice, plus any other processes that get schedule between times, before it will get a timeslice in which to go back and re-issue the accept.

This doesn't seem to be an issue there, and I don't think the much rarer possibility, will be an issue in a threaded model.