Remove the outdated notion that multithreading doesn't work well on Unices.

Doc/howto/sockets.rst

@@ -395,19 +395,13 @@ Performance
 
 There's no question that the fastest sockets code uses non-blocking sockets and
 select to multiplex them. You can put together something that will saturate a
-LAN connection without putting any strain on the CPU. The trouble is that an app
+LAN connection without putting any strain on the CPU.
-written this way can't do much of anything else - it needs to be ready to
-shuffle bytes around at all times.
 
-Assuming that your app is actually supposed to do something more than that,
+The trouble is that an app written this way can't do much of anything else -
-threading is the optimal solution, (and using non-blocking sockets will be
+it needs to be ready to shuffle bytes around at all times. Assuming that your
-faster than using blocking sockets). Unfortunately, threading support in Unixes
+app is actually supposed to do something more than that, threading is the
-varies both in API and quality. So the normal Unix solution is to fork a
+optimal solution, (and using non-blocking sockets will be faster than using
-subprocess to deal with each connection. The overhead for this is significant
+blocking sockets).
-(and don't do this on Windows - the overhead of process creation is enormous
-there). It also means that unless each subprocess is completely independent,
-you'll need to use another form of IPC, say a pipe, or shared memory and
-semaphores, to communicate between the parent and child processes.
 
 Finally, remember that even though blocking sockets are somewhat slower than
 non-blocking, in many cases they are the "right" solution. After all, if your