socket recall from that on windows multiprocessing passes context to new python interpreter process by pickling itand that process arguments must all be pickleable for windows sockets in python don' trigger errors when pickled thanks to the class they are an instance ofbut they are not really pickled correctlyfrom pickle import from socket import socket( dumps(ss loads(xx '\ \ csocket\nsocket\nq\ )\ \ } \ ( \ \ \ \ _io_refsq\ \ \ \ \ \ _closedq\ \ \ \ as we saw in multiprocessing has other ipc tools such as its own pipes and queues that might be used instead of sockets to work around this issuebut clients would then have to use themtoo--the resulting server would not be as broadly accessible as one based upon general internet sockets even if multiprocessing did work on windowsthoughits need to start new python interpreter would likely make it much slower than the more traditional technique of spawning threads to talk to clients coincidentallythat brings us to our next topic threading servers the forking model just described works well on unix-like platforms in generalbut it suffers from some potentially significant limitationsperformance on some machinesstarting new process can be fairly expensive in terms of time and space resources portability forking processes is unix techniqueas we've learnedthe os fork call currently doesn' work on non-unix platforms such as windows under standard python as we've also learnedforks can be used in the cygwin version of python on windowsbut they may be inefficient and not exactly the same as unix forks and as we just discoveredmultiprocessing won' help on windowsbecause connected sockets are not pickleable across process boundaries complexity if you think that forking servers can be complicatedyou're not alone as we just sawforking also brings with it all the shenanigans of managing and reaping zombies--cleaning up after child processes that live shorter lives than their parents handling multiple clients