while the gil is problem in the reference implementation of python that most people useit has been solved in some of the nonstandard implementations such as ironpython and jython unfortunatelyat the time of publicationnone of these support python thread overhead one final limitation of threads as compared to the asynchronous system we will be discussing later is the cost of maintaining the thread each thread takes up certain amount of memory (both in the python process and the operating system kernelto record the state of that thread switching between the threads also uses (smallamount of cpu time this work happens seamlessly without any extra coding (we just have to call start(and the rest is taken care of)but the work still has to happen somewhere this can be alleviated somewhat by structuring our workload so that threads can be reused to perform multiple jobs python provides threadpool feature to handle this it is shipped as part of the multiprocessing library and behaves identically to the processpoolthat we will discuss shortlyso let' defer discussion until the next section multiprocessing the multiprocessing api was originally designed to mimic the thread api howeverit has evolved and in recent versions of python it supports more features more robustly the multiprocessing library is designed when cpu-intensive jobs need to happen in parallel and multiple cores are available (given that four core raspberry pi can currently be purchased for $ there are usually multiple cores availablemultiprocessing is not useful when the processes spend majority of their time waiting on / (for examplenetworkdiskdatabaseor keyboard)but they are the way to go for parallel computation the multiprocessing module spins up new operating system processes to do the work on windows machinesthis is relatively expensive operationon linuxprocesses are implemented in the kernel the same way threads areso the overhead is limited to the cost of running separate python interpreters in each process