Speaking of unstable databases....
-
@Aaron said:
For the benefit of those who are not doing it right, could you please share what the right way is?
There is no golden hammer for this. It depends on what you're doing. It frequently involves an event loop and some different calls to the OS API.
To pick an example at random, let's say you were writing a tcp server in something congruent to C+POSIX. You could do it by having one thread sitting in a loop around an accept() call, and spawning a new thread for each session that connects. The right way, however, would be to set the O_NONBLOCK flag on the socket and build an event dispatch loop around a select() or poll() call.
The performance difference will usually be somewhere between 25% and 200%, depending on workload and operating system (Linux towards the low end, Windows is the worst).
@Aaron said:
the concepts of worker threads and callbacks were devised precisely for the purpose of eliminating the need for idle-event processing
No. They were devised precisely for the purpose of SMP. IO has nothing to do with it, and it never did. If you wanted to make the above server use multiple processors, you would put some worker threads in that the event loop dispatches jobs to, just like in any other SMP application.
@Aaron said:
when the performance difference becomes negligible (as it generally is for long-running worker threads)
Where did you get that idea? The performance difference is dictated by the amount of synchronisation required, and it does not normally change over the lifespan of the thread. You take about a 5%-10% hit from overloading the scheduler, and a massive hit every time cross-thread synchronisation is required.
